Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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