From: Vivek Goyal <vgoyal@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Josh Boyer <jwboyer@fedoraproject.org>,
"Theodore Ts'o" <tytso@mit.edu>, Petr Tesarik <ptesarik@suse.cz>,
kexec <kexec@lists.infradead.org>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
David Howells <dhowells@redhat.com>
Subject: Re: kexec_load(2) bypasses signature verification
Date: Thu, 18 Jun 2015 09:30:44 -0400 [thread overview]
Message-ID: <20150618133044.GA1040@redhat.com> (raw)
In-Reply-To: <20150618020209.GA8390@dhcp-128-32.nay.redhat.com>
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
> 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;
>
> /*
next prev parent reply other threads:[~2015-06-18 13:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 3:50 kexec_load(2) bypasses signature verification Theodore Ts'o
2015-06-15 12:14 ` Josh Boyer
2015-06-15 13:17 ` Theodore Ts'o
2015-06-15 13:37 ` Josh Boyer
2015-06-15 20:01 ` Theodore Ts'o
2015-06-16 19:38 ` Eric W. Biederman
2015-06-16 20:27 ` Vivek Goyal
2015-06-17 1:32 ` Eric W. Biederman
2015-06-17 1:47 ` Vivek Goyal
2015-06-18 1:16 ` Dave Young
2015-06-18 2:02 ` Dave Young
2015-06-18 13:30 ` Vivek Goyal [this message]
2015-06-18 14:41 ` Eric W. Biederman
2015-06-19 6:21 ` Dave Young
2015-06-19 8:18 ` Dave Young
2015-06-19 13:09 ` Vivek Goyal
2015-06-25 8:48 ` Dave Young
2015-06-25 15:59 ` Vivek Goyal
2015-06-26 1:59 ` Dave Young
2015-06-19 7:04 ` Dave Young
2015-06-19 13:09 ` Vivek Goyal
2015-06-17 3:26 ` Theodore Ts'o
2015-06-17 10:55 ` One Thousand Gnomes
2015-06-18 1:25 ` Dave Young
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150618133044.GA1040@redhat.com \
--to=vgoyal@redhat.com \
--cc=dhowells@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=jwboyer@fedoraproject.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptesarik@suse.cz \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox