Message-ID: <20131220141917.GB27063@redhat.com>
Date:	Fri, 20 Dec 2013 09:19:17 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Torsten Duwe <duwe@....de>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	kexec@...ts.infradead.org, hpa@...or.com,
	Peter Jones <pjones@...hat.com>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in
 kernel kexec

On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
> > On Tue, Nov 26, 2013 at 04:23:36AM -0800, Eric W. Biederman wrote:
> > > Vivek Goyal <vgoyal@...hat.com> writes:
> > > 
> > > > On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
> > > >
> > > 
> > > The init_size should be reflected in the .bss of the ELF segments.  If
> > > not it is a bug when generating the kernel ELF headers and should be
> > > fixed.
> > > 
> > > For use by kexec I don't see any issues with just signing the embedded
> > > ELF image.
> > 
> > Being able to write kernel to a file and then load it feels little odd to
> > me. Though this should be allowed but this should not be mandatory.
> > 
> > I think if we allow passing detached signature in kexec system call, then
> > it makes it much more flexible. We should be able to do what you are
> > suggesting at the same time it will also keep the possibility open for what
> > chromeOS developers are looking for.
> > 
> Support for detached signatures would be a big plus for kexec_file_load.
> 
> First I thought, some vendors are already shipping signed bzImages, why not
> verify these? But as it turns out, parsing MS-DOS, PE/COFF headers just to
> find the gaps is a lot of bloat for this little functionality. And David Howells
> got flamed quite badly when he suggested to add pkcs#7 to the kernel.

Yep, that's the reason I am not proposing parsing and verifying PE/COFF
signatures.

> IMO it's up to user land to search lists of certificates, and present
> only the final chain of trust to the kernel for checking.
> 
> ELF is the preferred format for most sane OSes and firmware, and a detached
> signature would probably be simplest to check. If we have the choice,
> without restrictions from braindead boot loaders, ELF should be first.
> And if the pesigning isn't usable and another sig is needed anyway,
> why not apply that to vmlinux(.gz) ?

I have yet to look deeper into it that if we can sign elf images and
just use elf loader. And can use space extract the elf image out of 
a bzImage and pass it to kernel.

Even if it is doable, one disadvantage seemed to be that extracted 
elf images will have to be written to a file so thta it's file descriptor
can be passed to kernel. And that assumed writable root and we chrome
folks seems to have setups where root is not writable.

> 
> Another remaining issue is the root of trust. Should the kernel solely depend
> on UeFI to check certificates? I'd rather vote for a compile-time fallback key.

I was thinking of signing kernel along the lines of modules. That is it is
RSA PKCS1 signatures. It does not contain certifiate chain. Signing key
should be in kernel and that key either can come from UEFI db, or user
might have added it in MOK during boot or we can embed one during kernel
build etc. Verification code will not care how did key show up in kernel.
There could be multiple ways.

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