From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932390AbbFROrM (ORCPT ); Thu, 18 Jun 2015 10:47:12 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:56906 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932166AbbFROq6 (ORCPT ); Thu, 18 Jun 2015 10:46:58 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Vivek Goyal Cc: Dave Young , Josh Boyer , "Theodore Ts'o" , Petr Tesarik , kexec , "Linux-Kernel\@Vger. Kernel. Org" , David Howells References: <20150615131728.GK15793@thunk.org> <20150615200115.GG5003@thunk.org> <87zj3zigug.fsf@x220.int.ebiederm.org> <20150616202757.GB14943@redhat.com> <87y4jjglvu.fsf@x220.int.ebiederm.org> <20150617014737.GB30214@redhat.com> <20150618011629.GA8718@dhcp-128-32.nay.redhat.com> <20150618020209.GA8390@dhcp-128-32.nay.redhat.com> <20150618133044.GA1040@redhat.com> Date: Thu, 18 Jun 2015 09:41:35 -0500 In-Reply-To: <20150618133044.GA1040@redhat.com> (Vivek Goyal's message of "Thu, 18 Jun 2015 09:30:44 -0400") Message-ID: <87r3p92i5c.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18jkhDkCn9ucOCcSD7BRIZM8e9gYW4KuOA= X-SA-Exim-Connect-IP: 67.3.205.90 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 T_XMDrugObfuBody_08 obfuscated drug references * 1.0 T_XMDrugObfuBody_04 obfuscated drug references * 0.5 XM_Body_Dirty_Words Contains a dirty word X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Vivek Goyal X-Spam-Relay-Country: X-Spam-Timing: total 360 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 8 (2.3%), b_tie_ro: 6 (1.6%), parse: 1.36 (0.4%), extract_message_metadata: 4.5 (1.3%), get_uri_detail_list: 1.93 (0.5%), tests_pri_-1000: 4.9 (1.4%), tests_pri_-950: 1.53 (0.4%), tests_pri_-900: 1.21 (0.3%), tests_pri_-400: 30 (8.3%), check_bayes: 28 (7.8%), b_tokenize: 7 (1.9%), b_tok_get_all: 8 (2.2%), b_comp_prob: 3.8 (1.0%), b_tok_touch_all: 2.9 (0.8%), b_finish: 0.95 (0.3%), tests_pri_0: 291 (80.7%), tests_pri_500: 6 (1.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: kexec_load(2) bypasses signature verification X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vivek Goyal 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z5b6H-0001A2-7b for kexec@lists.infradead.org; Thu, 18 Jun 2015 14:47:30 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <20150615131728.GK15793@thunk.org> <20150615200115.GG5003@thunk.org> <87zj3zigug.fsf@x220.int.ebiederm.org> <20150616202757.GB14943@redhat.com> <87y4jjglvu.fsf@x220.int.ebiederm.org> <20150617014737.GB30214@redhat.com> <20150618011629.GA8718@dhcp-128-32.nay.redhat.com> <20150618020209.GA8390@dhcp-128-32.nay.redhat.com> <20150618133044.GA1040@redhat.com> Date: Thu, 18 Jun 2015 09:41:35 -0500 In-Reply-To: <20150618133044.GA1040@redhat.com> (Vivek Goyal's message of "Thu, 18 Jun 2015 09:30:44 -0400") Message-ID: <87r3p92i5c.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Subject: Re: kexec_load(2) bypasses signature verification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Vivek Goyal Cc: Josh Boyer , Theodore Ts'o , Petr Tesarik , kexec , "Linux-Kernel@Vger. Kernel. Org" , David Howells , Dave Young Vivek Goyal 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