Re: Kdump with signed images

From: Matthew Garrett <mjg@redhat.com>
To: Khalid Aziz <khalid@gonehiking.org>
Cc: Kees Cook <keescook@chromium.org>,
	horms@verge.net.au, Dave Young <dyoung@redhat.com>,
	kexec@lists.infradead.org,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Dmitry Kasatkin <dmitry.kasatkin@intel.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Roberto Sassu <roberto.sassu@polito.it>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: Kdump with signed images
Date: Thu, 1 Nov 2012 16:23:15 +0000	[thread overview]
Message-ID: <20121101162315.GA13132@srcf.ucam.org> (raw)
In-Reply-To: <1351782656.3782.58.camel@rhapsody>

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@srcf.ucam.org

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec