From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754773AbbFPToA (ORCPT ); Tue, 16 Jun 2015 15:44:00 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:58370 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752722AbbFPTnu (ORCPT ); Tue, 16 Jun 2015 15:43:50 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Theodore Ts'o" Cc: Josh Boyer , David Howells , kexec , "Linux-Kernel\@Vger. Kernel. Org" , Vivek Goyal , Dave Young , Petr Tesarik References: <20150615035051.GA2634@thunk.org> <20150615131728.GK15793@thunk.org> <20150615200115.GG5003@thunk.org> Date: Tue, 16 Jun 2015 14:38:31 -0500 In-Reply-To: <20150615200115.GG5003@thunk.org> (Theodore Ts'o's message of "Mon, 15 Jun 2015 16:01:15 -0400") Message-ID: <87zj3zigug.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: U2FsdGVkX1+KeCHhb2cWPj5c+JPalUDLs5mlFcifpzo= 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 * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 TVD_RCVD_IP Message was received from an IP address * 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.4943] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Theodore Ts'o X-Spam-Relay-Country: X-Spam-Timing: total 1392 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 4.3 (0.3%), b_tie_ro: 3.1 (0.2%), parse: 0.86 (0.1%), extract_message_metadata: 3.1 (0.2%), get_uri_detail_list: 1.29 (0.1%), tests_pri_-1000: 4.1 (0.3%), tests_pri_-950: 1.76 (0.1%), tests_pri_-900: 1.56 (0.1%), tests_pri_-400: 31 (2.2%), check_bayes: 29 (2.1%), b_tokenize: 9 (0.6%), b_tok_get_all: 10 (0.7%), b_comp_prob: 3.7 (0.3%), b_tok_touch_all: 3.0 (0.2%), b_finish: 1.24 (0.1%), tests_pri_0: 1331 (95.6%), tests_pri_500: 5 (0.4%), 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 in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adding Vivek as he is the one who implemented kexec_file_load. I was hoping he would respond to this thread, and it looks like he simply has not ever been Cc'd. Theodore Ts'o writes: > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote: >> The bits that actually read Secure Boot state out of the UEFI >> variables, and apply protections to the machine to avoid compromise >> under the SB threat model. Things like disabling the old kexec... > > I don't have any real interest in using Secure Boot, but I *am* > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to > have something similar to what we have with signed modules in terms of > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for > KEXEC_VERIFY_SIG. This would mean creating a separate flag > independent of the one Linus suggested for Secure Boot, but since we > have one for signed modules, we do have precedent for this sort of > thing. My overall request with respect to kexec has been that we implement things that make sense outside of the bizarre threat model of the Linux folks who were talking about secure boot. nI have not navigated the labyrinth of config options but having a way to only boot signed things with kexec seems a completely sensible way to operate in the context of signed images. I don't know how much that will help given that actors with sufficient resources have demonstrated the ability to steal private keys, but assuming binary signing is an effective technique (or why else do it) then having an option to limit kexec to only loading signed images seems sensible. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out03.mta.xmission.com ([166.70.13.233]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z4wmZ-0000V2-1c for kexec@lists.infradead.org; Tue, 16 Jun 2015 19:44:27 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <20150615035051.GA2634@thunk.org> <20150615131728.GK15793@thunk.org> <20150615200115.GG5003@thunk.org> Date: Tue, 16 Jun 2015 14:38:31 -0500 In-Reply-To: <20150615200115.GG5003@thunk.org> (Theodore Ts'o's message of "Mon, 15 Jun 2015 16:01:15 -0400") Message-ID: <87zj3zigug.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: Theodore Ts'o Cc: Josh Boyer , Petr Tesarik , kexec , "Linux-Kernel@Vger. Kernel. Org" , David Howells , Dave Young , Vivek Goyal Adding Vivek as he is the one who implemented kexec_file_load. I was hoping he would respond to this thread, and it looks like he simply has not ever been Cc'd. Theodore Ts'o writes: > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote: >> The bits that actually read Secure Boot state out of the UEFI >> variables, and apply protections to the machine to avoid compromise >> under the SB threat model. Things like disabling the old kexec... > > I don't have any real interest in using Secure Boot, but I *am* > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to > have something similar to what we have with signed modules in terms of > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for > KEXEC_VERIFY_SIG. This would mean creating a separate flag > independent of the one Linus suggested for Secure Boot, but since we > have one for signed modules, we do have precedent for this sort of > thing. My overall request with respect to kexec has been that we implement things that make sense outside of the bizarre threat model of the Linux folks who were talking about secure boot. nI have not navigated the labyrinth of config options but having a way to only boot signed things with kexec seems a completely sensible way to operate in the context of signed images. I don't know how much that will help given that actors with sufficient resources have demonstrated the ability to steal private keys, but assuming binary signing is an effective technique (or why else do it) then having an option to limit kexec to only loading signed images seems sensible. Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec