From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932163Ab3KVQ1w (ORCPT ); Fri, 22 Nov 2013 11:27:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5513 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755721Ab3KVQ1v (ORCPT ); Fri, 22 Nov 2013 11:27:51 -0500 Date: Fri, 22 Nov 2013 10:33:50 -0500 From: Vivek Goyal To: Jiri Kosina Cc: Geert Uytterhoeven , "Eric W. Biederman" , "linux-kernel@vger.kernel.org" , kexec@lists.infradead.org, "H. Peter Anvin" , Matthew Garrett , Greg Kroah-Hartman , Kees Cook Subject: Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading Message-ID: <20131122153349.GH4046@redhat.com> References: <1384969851-7251-1-git-send-email-vgoyal@redhat.com> <8761rl73s7.fsf@xmission.com> <20131122015518.GA31921@redhat.com> <20131122134600.GC4046@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 22, 2013 at 02:50:43PM +0100, Jiri Kosina wrote: > On Fri, 22 Nov 2013, Vivek Goyal wrote: > > > > OTOH, does this feature make any sense whatsover on architectures that > > > don't support secure boot anyway? > > > > I guess if signed modules makes sense, then being able to kexec signed > > kernel images should make sense too, in general. > > Well, that's really a grey zone, I'd say. > > In a non-secureboot environment, if you are root, you are able to issue > reboot into a completely different, self-made kernel anyway, independent > on whether signed modules are used or not. That's a good poing. Frankly speaking I don't know if there is a good use case to allow loading signed kernels only or not. Kees mentioned that he would like to know where the kernel came from and whether it came from trusted disk or not. So he does seem to have a use case where he wants to launch only trusted kernel or deny execution. Thanks Vivek