[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121101162315.GA13132@srcf.ucam.org>
Date: Thu, 1 Nov 2012 16:23:15 +0000
From: Matthew Garrett <mjg@...hat.com>
To: Khalid Aziz <khalid@...ehiking.org>
Cc: Vivek Goyal <vgoyal@...hat.com>,
Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
Kees Cook <keescook@...omium.org>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
kexec@...ts.infradead.org,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
horms@...ge.net.au, "Eric W. Biederman" <ebiederm@...ssion.com>,
"H. Peter Anvin" <hpa@...or.com>,
Roberto Sassu <roberto.sassu@...ito.it>,
Dave Young <dyoung@...hat.com>
Subject: Re: Kdump with signed images
On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
> On Thu, 2012-11-01 at 14:57 +0000, Matthew Garrett wrote:
> > On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:
> >
> > > And if one wants only /sbin/kexec to call it, then just sign that
> > > one so no other executable will be able to call kexec_load(). Though
> > > I don't think that's the requirement here. Requirement is that only
> > > trusted executables should be able to call kexec_load().
> >
> > Where "trusted executables" means "signed by a key that's present in the
> > system firmware or in the kernel that's signed with a key that's present
> > in the system firmware", sure.
> >
>
> This is starting to sound too restrictive (even though I understand the
> rationale behind the restrictions). Does this allow for a custom
> userspace application that among other things also can kexec_load() a
> new kernel and boot it, for example a customer unique health monitoring
> app that reboots the system if things are not looking right on the
> running system?
Only if it's signed with a key that the kernel trusts.
> How would a customer go about getting that userspace binary signed and
> re-signed every time they update their app? There is the option of
> turning the whole SecureBoot thing off for a system like that but let
> us assume customer wants to leave that on or does not have the option
> to turn it off?
There's ongoing work for providing mechanisms for trusting user keys. If
you want Secure Boot turned on, you don't want any untrusted code
running in your kernel. If you're happy with untrusted code in your
kernel, why are you using Secure Boot?
--
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists