Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1165005 > unrolled thread

kexec_load(2) bypasses signature verification

Back to article view | Back to linux.kernel

Contents

  kexec_load(2) bypasses signature verification Theodore Ts'o <tytso@mit.edu> - 2015-06-15 06:00 +0200
    Re: kexec_load(2) bypasses signature verification Theodore Ts'o <tytso@mit.edu> - 2015-06-15 22:10 +0200
      Re: kexec_load(2) bypasses signature verification ebiederm@xmission.com (Eric W. Biederman) - 2015-06-16 21:50 +0200
        Re: kexec_load(2) bypasses signature verification Vivek Goyal <vgoyal@redhat.com> - 2015-06-16 22:30 +0200
          Re: kexec_load(2) bypasses signature verification Dave Young <dyoung@redhat.com> - 2015-06-18 03:20 +0200
            Re: kexec_load(2) bypasses signature verification Dave Young <dyoung@redhat.com> - 2015-06-18 04:10 +0200
              Re: kexec_load(2) bypasses signature verification Dave Young <dyoung@redhat.com> - 2015-06-19 08:30 +0200
                Re: kexec_load(2) bypasses signature verification Dave Young <dyoung@redhat.com> - 2015-06-19 10:20 +0200
                  Re: kexec_load(2) bypasses signature verification Vivek Goyal <vgoyal@redhat.com> - 2015-06-19 15:10 +0200
          Re: kexec_load(2) bypasses signature verification Dave Young <dyoung@redhat.com> - 2015-06-19 09:10 +0200
            Re: kexec_load(2) bypasses signature verification Vivek Goyal <vgoyal@redhat.com> - 2015-06-19 15:10 +0200
      Re: kexec_load(2) bypasses signature verification Dave Young <dyoung@redhat.com> - 2015-06-18 03:30 +0200

#1165005 — kexec_load(2) bypasses signature verification

From experimentation and from looking at the sources, it appears that
the signature checking is only done in the kexec_file_load(2) system
all, and not in the kexec_load(2) system call.  And I understand why
-- the signature is not sent from userspace to the kernel in the older
kexec_load(2) system call.

The problem is that if you use an old version of kexec, it will use
the old kexec_load(2) system call, and even though
CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an
unsigned kernel, and then "kexec -e" will happily boot into it.

Correct me if I am wrong, but this appears to be a hole in Secure Boot
you could drive a Mack Truck through.

(I noticed this because Debian is still using a kexec-tools from the
stone ages, version 2.0.7, and I was wondering **why** I was able to
kexec boot completely unsigned kernels.)

It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the
old kexec_load(2) system call should be disabled (and a warning be
placed in the Kconfig help that the user should have at least verision
2.X of kexec-tools if they enable this kernel option).

Am I missing something?

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1165521

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.

						- Ted

[1] Yes, it doesn't buy all that much, since if the system is rooted
the adversary can just replace the kernel in /boot and force a normal,
slower reboot, but the same could be said for signed modules --- the
adversary could just replace all of /boot/vmlinux-<kver> and
/lib/modules/<kver>.  But both measures make it a tad more bit
difficult, especially for the adversary to do this replacement without
being noticed (for example linode will send me e-mail if the system
reboots normally, but not with a kexec-mediated reboot), and for cloud
systems where we don't have secure boot anyway, it's about the best we
can do.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1166345

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@mit.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.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1166379

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@mit.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1167520

On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> > 
> > > 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@mit.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.
> > 
> > Interesting.
> > 
> > I suspect that what we want is to have CONFIG_KEXEC for the core
> > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> > 
> > That should make it trivially easy to disable the kexec_load system call
> > in cases where people care.
> 
> Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> which will be automatically selected when either CONFIG_KEXEC or
> CONIG_KEXEC_FILE are selected.
> 
> All common code can go under this option and rest can go under respective
> config options.
> 
> That way, those who have CONFIG_KEXEC=y in old config files will not be
> broken. They don't have to learn about new options at all.

Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
error in kexec_load and print some error message.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1167531

On 06/18/15 at 09:16am, Dave Young wrote:
> On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> > On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > > Vivek Goyal <vgoyal@redhat.com> writes:
> > > 
> > > > 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@mit.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.
> > > 
> > > Interesting.
> > > 
> > > I suspect that what we want is to have CONFIG_KEXEC for the core
> > > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> > > 
> > > That should make it trivially easy to disable the kexec_load system call
> > > in cases where people care.
> > 
> > Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> > which will be automatically selected when either CONFIG_KEXEC or
> > CONIG_KEXEC_FILE are selected.
> > 
> > All common code can go under this option and rest can go under respective
> > config options.
> > 
> > That way, those who have CONFIG_KEXEC=y in old config files will not be
> > broken. They don't have to learn about new options at all.
> 
> Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
> error in kexec_load and print some error message.

Just like below, does this work for you, Ted?

---
 arch/x86/Kconfig |    7 +++++++
 kernel/kexec.c   |    9 ++++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)

--- linux.orig/arch/x86/Kconfig
+++ linux/arch/x86/Kconfig
@@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
 	  verification for the corresponding kernel image type being
 	  loaded in order for this to work.
 
+config KEXEC_VERIFY_SIG_FORCE
+	bool "Enforce kexec signature verifying"
+	depends on KEXEC_VERIFY_SIG
+	---help---
+	  This option disable kexec_load() syscall, only kexec_file_load
+ 	  can be used.
+
 config KEXEC_BZIMAGE_VERIFY_SIG
 	bool "Enable bzImage signature verification support"
 	depends on KEXEC_VERIFY_SIG
--- linux.orig/kernel/kexec.c
+++ linux/kernel/kexec.c
@@ -45,6 +45,12 @@
 #include <crypto/hash.h>
 #include <crypto/sha.h>
 
+#ifdef CONFIG_KEXEC_VERIFY_SIG_FORCE
+static bool kexec_verify_sig_force = true;
+#else
+static bool kexec_verify_sig_force;
+#endif
+
 /* Per cpu memory for storing cpu states in case of system crash. */
 note_buf_t __percpu *crash_notes;
 
@@ -1243,7 +1249,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
 	int result;
 
 	/* We only trust the superuser with rebooting the system. */
-	if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
+	if (!capable(CAP_SYS_BOOT) || kexec_load_disabled
+	    || kexec_verify_sig_force)
 		return -EPERM;
 
 	/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1168557

On 06/18/15 at 09:30am, Vivek Goyal wrote:
> On Thu, Jun 18, 2015 at 10:02:09AM +0800, Dave Young wrote:
> 
> [..]
> > > Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
> > > error in kexec_load and print some error message.
> > 
> > Just like below, does this work for you, Ted?
> > 
> > ---
> >  arch/x86/Kconfig |    7 +++++++
> >  kernel/kexec.c   |    9 ++++++++-
> >  2 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > --- linux.orig/arch/x86/Kconfig
> > +++ linux/arch/x86/Kconfig
> > @@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
> >  	  verification for the corresponding kernel image type being
> >  	  loaded in order for this to work.
> >  
> > +config KEXEC_VERIFY_SIG_FORCE
> > +	bool "Enforce kexec signature verifying"
> > +	depends on KEXEC_VERIFY_SIG
> > +	---help---
> > +	  This option disable kexec_load() syscall, only kexec_file_load
> > + 	  can be used.
> > +
> 
> 
> Hi Dave,
> 
> I think we might not need a new config option. A new config option makes
> it little confusing. KEXEC_VERIFY_SIG already implies KEXEC_VERIFY_SIG_FORCE
> (for new syscall). Now extending it to also mean that it should disable old
> syscall is confusing.

Hmm, it is only reasonable when kexec_file_load can support bypassing sig
verifying even when CONFIG_KEXEC_VERIFY_SIG=y.

So agree it is confusing to add a _FORCE new option now.

> 
> We already have a sysctl knob to disable kexec kernel loading. But that
> knob disables it on both the syscalls.
> 
> May be we can just introduce another command line option say
> "kexec_verify_sig_force" and this will work across both the syscalls and
> will deny loading a unsigned kernel in following two cases.
> 
> - Using old syscall
> - Using new syscall if kernel was compiled with KEXEC_VERIFY_SIG=n.

As you said KEXEC_VERIFY_SIG implies KEXEC_VERIFY_SIG_FORCE now so if one
disable it in .config, we have no reason to disable kernel loading without
signature verifying? 

> 
> This should be simple and get us going in short term.
> 
> If we want to disable unsigned kernel loading at compile time, then we
> really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> Introducing another config option is not the way forward, IMHO.

Yes, let's do it in this way since everyone is fine with it.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1168604

> > If we want to disable unsigned kernel loading at compile time, then we
> > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > Introducing another config option is not the way forward, IMHO.
> 
> Yes, let's do it in this way since everyone is fine with it.

I will work on a patch if nobody else have interest or no time on it.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1168764

On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > If we want to disable unsigned kernel loading at compile time, then we
> > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > Introducing another config option is not the way forward, IMHO.
> > 
> > Yes, let's do it in this way since everyone is fine with it.
> 
> I will work on a patch if nobody else have interest or no time on it.

Thanks Dave. Will be good if you can get this done.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1168571

On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> > 
> > > 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@mit.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.
> > 
> > Interesting.
> > 
> > I suspect that what we want is to have CONFIG_KEXEC for the core
> > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> > 
> > That should make it trivially easy to disable the kexec_load system call
> > in cases where people care.
> 
> Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> which will be automatically selected when either CONFIG_KEXEC or
> CONIG_KEXEC_FILE are selected.
> 
> All common code can go under this option and rest can go under respective
> config options.
> 
> That way, those who have CONFIG_KEXEC=y in old config files will not be
> broken. They don't have to learn about new options at all.

Vivek, It is slight better for reusing old config file, but CONFIG_KEXEC_LOAD
sounds better. Do we have to maintain the compability for kconfig?

KEXEC_COMMON/KEXEC/KEXEC_FILE_LOAD is a little confusing. CONFIG_KEXEC
should be the common kexec stuff naturally, it is strange to use CONFIG_KEXEC
for only kexec_load syscall.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1168765

On Fri, Jun 19, 2015 at 03:04:31PM +0800, Dave Young wrote:
> On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> > On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > > Vivek Goyal <vgoyal@redhat.com> writes:
> > > 
> > > > 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@mit.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.
> > > 
> > > Interesting.
> > > 
> > > I suspect that what we want is to have CONFIG_KEXEC for the core
> > > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> > > 
> > > That should make it trivially easy to disable the kexec_load system call
> > > in cases where people care.
> > 
> > Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> > which will be automatically selected when either CONFIG_KEXEC or
> > CONIG_KEXEC_FILE are selected.
> > 
> > All common code can go under this option and rest can go under respective
> > config options.
> > 
> > That way, those who have CONFIG_KEXEC=y in old config files will not be
> > broken. They don't have to learn about new options at all.
> 
> Vivek, It is slight better for reusing old config file, but CONFIG_KEXEC_LOAD
> sounds better. Do we have to maintain the compability for kconfig?
> 
> KEXEC_COMMON/KEXEC/KEXEC_FILE_LOAD is a little confusing. CONFIG_KEXEC
> should be the common kexec stuff naturally, it is strange to use CONFIG_KEXEC
> for only kexec_load syscall.

Hi Dave,

I think as a user I would like my old config file to work with new kernel.
It is a good idea to keep old config options until and unless we have a
very good reason.

To me following should be reasonable.

CONFIG_KEXEC --> Enable old syscall
CONFIG_FILE_KEXEC --> Enable new syscall

In fact we might not have to introduce CONFIG_KEXEC_COMMON. We can
just use

#ifdef (CONFIG_KEXEC) | ifdef (CONFIG_FILE_KEXEC
  /* Common code between two syscalls */
#endif

That way we don't introduce any new config options and stick to existing
ones. 

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1167522

On 06/15/15 at 04:01pm, Theodore Ts'o wrote:
> 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.

Agree and vote for this way as I replied in another email about
CONFIG_KEXEC_VERIFY_SIG_FORCE.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web