[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1351875469.25914.51.camel@rhapsody>
Date: Fri, 02 Nov 2012 10:57:49 -0600
From: Khalid Aziz <khalid@...ehiking.org>
To: Matthew Garrett <mjg@...hat.com>
Cc: Kees Cook <keescook@...omium.org>, horms@...ge.net.au,
Dave Young <dyoung@...hat.com>, kexec@...ts.infradead.org,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"H. Peter Anvin" <hpa@...or.com>,
Roberto Sassu <roberto.sassu@...ito.it>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
Vivek Goyal <vgoyal@...hat.com>
Subject: Re: Kdump with signed images
On Thu, 2012-11-01 at 16:23 +0000, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
> > 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?
>
I would argue code written by a customer to run on their own systems is
inherently trusted code and does not invalidate need/desire for Secure
Boot. So the customer will still need some way to get their binary
signed very painlessly just so they could use their own binary on their
own system, simply because of a heavily locked down system design by
Linux community.
--
Khalid
--
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