kexec_load(2) bypasses signature verification

[Theodore Ts'o]

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

[Josh Boyer]

On Sun, Jun 14, 2015 at 11:50 PM, Theodore Ts'o <ty...@mit.edu> wrote:
> 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.

Yes, which is why most of the distro vendors carry an out-of-tree
patch that disables the old kexec in an SB setup. It would be nice if
we could merge said patches. However, they depend on Matthew's
secure_modules/trusted_kernel/<whatever name that works> patchset
which has gotten little movement since we came up with a tentative
agreement at LPC 2013.

> (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?

Those sound like fine suggestions to me.

josh

[Theodore Ts'o]

On Mon, Jun 15, 2015 at 08:14:19AM -0400, Josh Boyer wrote:
> Yes, which is why most of the distro vendors carry an out-of-tree
> patch that disables the old kexec in an SB setup. It would be nice if
> we could merge said patches. However, they depend on Matthew's
> secure_modules/trusted_kernel/<whatever name that works> patchset
> which has gotten little movement since we came up with a tentative
> agreement at LPC 2013.

Signed modules is in, though, right? And the fact that we have
CONFIG_SIGNED_PE_FILE_VERIFICATION means we're doing unatural file
signatures w/o using ELF, which I thought was the basis of Linus's
accusation that Red Hat was performing intimate/physical acts with
Microsoft. :-)

I would have thought those were the nasty bits to get in; out of
curiosity, what's still missing?

Regards,

- Ted

[Josh Boyer]

On Mon, Jun 15, 2015 at 9:17 AM, Theodore Ts'o <ty...@mit.edu> wrote:
> On Mon, Jun 15, 2015 at 08:14:19AM -0400, Josh Boyer wrote:
>> Yes, which is why most of the distro vendors carry an out-of-tree
>> patch that disables the old kexec in an SB setup. It would be nice if
>> we could merge said patches. However, they depend on Matthew's
>> secure_modules/trusted_kernel/<whatever name that works> patchset
>> which has gotten little movement since we came up with a tentative
>> agreement at LPC 2013.
>
> Signed modules is in, though, right? And the fact that we have

Yes.

> CONFIG_SIGNED_PE_FILE_VERIFICATION means we're doing unatural file
> signatures w/o using ELF, which I thought was the basis of Linus's
> accusation that Red Hat was performing intimate/physical acts with
> Microsoft. :-)
>
> I would have thought those were the nasty bits to get in; out of
> curiosity, what's still missing?

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,
enforcing module signatures at runtime, restricting various access
(like /dev/mem, /dev/kmem), adding certs in UEFI db to the system
keyring, and enforcing the UEFI dbx blacklist. So most of the patches
in Matthew's set relate to enforcement using the bits of functionality
already merged. They aren't even strictly tied to UEFI or SB, but
some of the other patches distos carry are. We had tentative
agreement even from Linus on much of this (his words were along the
lines of "create a flag and use the flag"), but it's failed to
actually get carried in any tree for a few reasons.

josh

[Theodore Ts'o]

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.

[Eric W. Biederman]

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

[Vivek Goyal]

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

[Eric W. Biederman]

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.

Eric

[Vivek Goyal]

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.

Thanks
Vivek

[Theodore Ts'o]

On Tue, Jun 16, 2015 at 04:27:57PM -0400, Vivek Goyal wrote:
>
> 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.

Either compiled out or disabled via some flag (similar to how signed
moduled verification can be required via a flag that can be set, but
not unset once it is set), yes.

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

That would certianly also be a workable strategy.

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

Well, note that Debian and Ubuntu are still using kexec-tools 2.0.7
(even in their latest development/unstable releases), which doesn't
have support for kexec_file_load(). So we need to get Debian to
upgrade its kexec-tools as part of this. I'll try to file a
nag-o-gram to the Debian BTS.

- Ted

[One Thousand Gnomes]

> [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.

It's about the same as the protection offered by the "secure" boot
patches I've seen because they don't block all kernel boot parameters
except a whitelist and because there are a pile of other fairly
fundamental problems that probably require you also sign the root file
system, which is itself a world of pain.

Alan

[Dave Young]

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

[Dave Young]

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

[Dave Young]

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;

/*

[Vivek Goyal]

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.

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.

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.

Thanks
Vivek

[Eric W. Biederman]

Agreed.

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

Agreed.

I think disabling kexec_load at compile time can be easily justified.

Anything at runtime is additional complexity, additional bugs,
additional documentation and additional maintenance and needs
to justify itself.

I currently do not see the case for a magic one time runtime disable of
the kexec_load system call. Maybe there is some valid distro case for
wanting one kernel to do everything and serve every possible need, but I
have not seen that case presented yet.

Eric

[Dave Young]

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

[Dave Young]

On 06/16/15 at 09:47pm, Vivek Goyal wrote:

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

[Dave Young]

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

[Vivek Goyal]

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

[Vivek Goyal]

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

[Dave Young]

On 06/19/15 at 09:09am, Vivek Goyal wrote:
> 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.

Vivek, I worked out some draft patches here:
https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup

Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option
then split kexec_load code from general code.

There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC
can be disabled so I changed all kernel general and x86 #ifdef to use
CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef
I did not change anything other than the new Kconfig option. It will works
because only x86 support KEXEC_FILE.

Please take a look if you have time, if this is not what you want please let
me know.

I will have no time this week, only did building test, will do more test next
week, if everything is ok I can send out the patches to list for review.

Thanks
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Vivek Goyal]

On Thu, Jun 25, 2015 at 04:48:18PM +0800, Dave Young wrote:
> On 06/19/15 at 09:09am, Vivek Goyal wrote:
> > 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.
>
> Vivek, I worked out some draft patches here:
> https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup
>
> Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option
> then split kexec_load code from general code.
>
> There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC
> can be disabled so I changed all kernel general and x86 #ifdef to use
> CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef
> I did not change anything other than the new Kconfig option. It will works
> because only x86 support KEXEC_FILE.
>
> Please take a look if you have time, if this is not what you want please let
> me know.
>
> I will have no time this week, only did building test, will do more test next
> week, if everything is ok I can send out the patches to list for review.

Hi Dave,

I have put few comments in github. Please have a look. Once you have
another version of patches, I will have another look.

Thanks
Vivek

[Dave Young]

Vivek, thanks a lot. Will have a look.

Dave