From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752722AbcGMIhA (ORCPT ); Wed, 13 Jul 2016 04:37:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37947 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751013AbcGMIgs (ORCPT ); Wed, 13 Jul 2016 04:36:48 -0400 Date: Wed, 13 Jul 2016 16:36:32 +0800 From: Dave Young To: Russell King - ARM Linux Cc: Stewart Smith , Petr Tesarik , linux-arm-kernel@lists.infradead.org, bhe@redhat.com, arnd@arndb.de, linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro , "Eric W. Biederman" , Thiago Jung Bauermann , vgoyal@redhat.com Subject: Re: [RFC 0/3] extend kexec_file_load system call Message-ID: <20160713083632.GA14038@dhcp-128-65.nay.redhat.com> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <87furf7ztv.fsf@x220.int.ebiederm.org> <50662781.Utjsnse3nb@hactar> <20160712225805.0d27fe5d@hananiah.suse.cz> <20160712221804.GV1041@n2100.armlinux.org.uk> <87twfunneg.fsf@linux.vnet.ibm.com> <20160713073657.GX1041@n2100.armlinux.org.uk> <87poqinf9m.fsf@linux.vnet.ibm.com> <20160713082639.GZ1041@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160713082639.GZ1041@n2100.armlinux.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 13 Jul 2016 08:36:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [snip] > Now, going back to the more fundamental issue raised in my first reply, > about the kernel command line. > > On x86, I can see that it _is_ possible for userspace to specify a > command line, and the kernel loading the image provides the command > line to the to-be-kexeced kernel with very little checking. So, if > your kernel is signed, what stops the "insecure userspace" loading > a signed kernel but giving it an insecure rootfs and/or console? The kexec_file_load syscall was introduced for secure boot in the first place. In case UEFI secure boot the signature verification chain only covers kernel mode binaries. I think there is such problem in both normal boot and kexec boot. Thanks Dave