Date:	Tue, 16 Jun 2015 16:27:57 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Theodore Ts'o" <tytso@....edu>,
	Josh Boyer <jwboyer@...oraproject.org>,
	David Howells <dhowells@...hat.com>,
	kexec <kexec@...ts.infradead.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Dave Young <dyoung@...hat.com>, Petr Tesarik <ptesarik@...e.cz>
Subject: Re: kexec_load(2) bypasses signature verification

On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> 
> Adding Vivek as he is the one who implemented kexec_file_load.
> I was hoping he would respond to this thread, and it looks like he
> simply has not ever been Cc'd.
> 
> Theodore Ts'o <tytso@....edu> writes:
> 
> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> >> The bits that actually read Secure Boot state out of the UEFI
> >> variables, and apply protections to the machine to avoid compromise
> >> under the SB threat model.  Things like disabling the old kexec...
> >
> > I don't have any real interest in using Secure Boot, but I *am*
> > interested in using CONFIG_KEXEC_VERIFY_SIG[1].  So perhaps we need to
> > have something similar to what we have with signed modules in terms of
> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > KEXEC_VERIFY_SIG.  This would mean creating a separate flag
> > independent of the one Linus suggested for Secure Boot, but since we
> > have one for signed modules, we do have precedent for this sort of
> > thing.
> 
> My overall request with respect to kexec has been that we implement
> things that make sense outside of the bizarre threat model of the Linux
> folks who were talking about secure boot.
> 
> nI have not navigated the labyrinth of config options but having a way to
> only boot signed things with kexec seems a completely sensible way to
> operate in the context of signed images.
> 
> I don't know how much that will help given that actors with sufficient
> resources have demonstrated the ability to steal private keys, but
> assuming binary signing is an effective technique (or why else do it)
> then having an option to limit kexec to only loading signed images seems
> sensible.

I went through the mail chain on web and here are my thoughts.

- So yes, upstream does not have the logic which automatically disables
  the old syscall (kexec_load()) on secureboot systems. Distributions
  carry those patches.

- This KEXEC_VERIFY_SIG option only cotrols the behavior for
  kexec_file_load() syscall and is not meant to directly affect any
  behavior of old syscall (kexec_load()). I think I should have named
  it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
  "Verify kernel signature during kexec_file_load() syscall".

- I think disabling old system call if KEXEC_VERIFY_SIG() is set
  will break existing setup which use old system call by default, except
  the case of secureboot system. And old syscall path is well tested
  and new syscall might not be in a position to support all the corner
  cases, atleast as of now.

Ted, 

So looks like you are looking for a system/option where you just want to
always make use of kexec_file_load() and disable kexec_load(). This sounds
like you want a kernel where kexec_load() is compiled out and you want
only kexec_file_load() in.

Right now one can't do that becase kexec_file_load() depends on
CONFIG_KEXEC option.

I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
only signed kernel can be kexeced on that system.

This should gel well with long term strategy of deprecating kexec_load()
at some point of time when kexec_file_load() is ready to completely
replace it.

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