kexec_load(2) bypasses signature verification
dyoung at redhat.com
Thu Jun 18 23:21:40 PDT 2015
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
> 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.
More information about the kexec