From: ebiederm@xmission.com (Eric W. Biederman)
To: Vivek Goyal <vgoyal@redhat.com>
Cc: 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>,
Dave Young <dyoung@redhat.com>
Subject: Re: kexec_load(2) bypasses signature verification
Date: Thu, 18 Jun 2015 09:41:35 -0500 [thread overview]
Message-ID: <87r3p92i5c.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20150618133044.GA1040@redhat.com> (Vivek Goyal's message of "Thu, 18 Jun 2015 09:30:44 -0400")
Vivek Goyal <vgoyal@redhat.com> writes:
> 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.
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-06-18 14:47 UTC|newest]
Thread overview: 26+ 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 9:11 ` Dave Young
2015-06-15 9:28 ` Petr Tesarik
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
2015-06-18 14:41 ` Eric W. Biederman [this message]
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=87r3p92i5c.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=dhowells@redhat.com \
--cc=dyoung@redhat.com \
--cc=jwboyer@fedoraproject.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptesarik@suse.cz \
--cc=tytso@mit.edu \
--cc=vgoyal@redhat.com \
/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