From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VYMNn-0002su-FA for mharc-grub-devel@gnu.org; Mon, 21 Oct 2013 16:47:23 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYGPn-00086z-4d for grub-devel@gnu.org; Mon, 21 Oct 2013 10:25:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYGPg-0004Wj-EP for grub-devel@gnu.org; Mon, 21 Oct 2013 10:25:03 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:28754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYGPg-0004WW-6y for grub-devel@gnu.org; Mon, 21 Oct 2013 10:24:56 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LENpuj017380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 14:23:51 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LENniT029527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 14:23:50 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LENnau006388; Mon, 21 Oct 2013 14:23:49 GMT Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Oct 2013 07:23:49 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7CFB01BF6F2; Mon, 21 Oct 2013 10:23:47 -0400 (EDT) Date: Mon, 21 Oct 2013 10:23:47 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Subject: Re: EFI and multiboot2 devlopment work for Xen Message-ID: <20131021142347.GB4211@phenom.dumpdata.com> References: <20131021125756.GA3626@debian70-amd64.local.net-space.pl> <52654A0602000078000FC611@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52654A0602000078000FC611@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-Mailman-Approved-At: Mon, 21 Oct 2013 16:47:21 -0400 Cc: grub-devel@gnu.org, keir@xen.org, david.woodhouse@intel.com, stefano.stabellini@eu.citrix.com, Daniel Kiper , linux-kernel@vger.kernel.org, ross.philipson@citrix.com, xen-devel , boris.ostrovsky@oracle.com, richard.l.maliszewski@intel.com, ian.campbell@citrix.com X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:25:08 -0000 On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote: > >>> On 21.10.13 at 14:57, Daniel Kiper wrote: > > (Looking at the Cc list it's quite interesting that you copied a > whole lot of people, but not me as the maintainer of the EFI > bits in Xen.) I see this: From: Daniel Kiper To: boris.ostrovsky@oracle.com, david.woodhouse@intel.com, ian.campbell@citrix.com, jbeulich@suse.com, keir@xen.org, You are on the 'To' instead of the 'CC'. That should make the email arrive at your mailbox much quicker than through the mailing list? > > > Separate multiboot2efi module should be established. It should verify system > > kernel and all loaded modules using shim on EFI platforms with enabled > > secure boot > > Each involved component verifies only the next image. I.e. the > shim verifies the Xen image, and Xen verifies the Dom0 kernel > binary. The Dom0 kernel (assuming it to be Linux) will then be > responsible for dealing with its initrd. (One open question is how > Xen ought to deal with an eventual XSM module; I take it that > the CPUs themselves take care of the microcode blob.) This can't > be different because the shim provided verification protocol > assumes that it's being handed a PE image (hence the need for > Linux to package itself as a fake PE image), and hence can't be > used for verifying other than the Xen and Dom0 kernel binaries. > > > At first I am going to prepare multiboot2 protocol implementation for Xen > > (there > > is about 80% of code ready) with above mentioned workaround. > > Is that really worthwhile as long as it's not clear whether ... > > > Later I am going to work on multiboot2efi module. > > ... is going to be accepted? > > > What do you think about that? > > Any comments, suggestions, objections? > > The complications here make it pretty clear to me that the > GrUB2-less solution (or, if GruB2 absolutely has to be involved, > its chain loading capability) I have been advocating continues > to be the better (and, as said before, conceptually correct) > model. However my understanding is that the general distro approach is to use GRUB2 and I think we want to follow the mainstream on this. Which means using GRUB2 and making sense of the myrid of patches that each distro has. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754115Ab3JUOZ3 (ORCPT ); Mon, 21 Oct 2013 10:25:29 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:35896 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753215Ab3JUOZ2 (ORCPT ); Mon, 21 Oct 2013 10:25:28 -0400 Date: Mon, 21 Oct 2013 10:23:47 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Cc: Daniel Kiper , ian.campbell@citrix.com, ross.philipson@citrix.com, stefano.stabellini@eu.citrix.com, grub-devel@gnu.org, david.woodhouse@intel.com, richard.l.maliszewski@intel.com, xen-devel , boris.ostrovsky@oracle.com, pjones@redhat.com, linux-kernel@vger.kernel.org, keir@xen.org Subject: Re: EFI and multiboot2 devlopment work for Xen Message-ID: <20131021142347.GB4211@phenom.dumpdata.com> References: <20131021125756.GA3626@debian70-amd64.local.net-space.pl> <52654A0602000078000FC611@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52654A0602000078000FC611@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote: > >>> On 21.10.13 at 14:57, Daniel Kiper wrote: > > (Looking at the Cc list it's quite interesting that you copied a > whole lot of people, but not me as the maintainer of the EFI > bits in Xen.) I see this: From: Daniel Kiper To: boris.ostrovsky@oracle.com, david.woodhouse@intel.com, ian.campbell@citrix.com, jbeulich@suse.com, keir@xen.org, You are on the 'To' instead of the 'CC'. That should make the email arrive at your mailbox much quicker than through the mailing list? > > > Separate multiboot2efi module should be established. It should verify system > > kernel and all loaded modules using shim on EFI platforms with enabled > > secure boot > > Each involved component verifies only the next image. I.e. the > shim verifies the Xen image, and Xen verifies the Dom0 kernel > binary. The Dom0 kernel (assuming it to be Linux) will then be > responsible for dealing with its initrd. (One open question is how > Xen ought to deal with an eventual XSM module; I take it that > the CPUs themselves take care of the microcode blob.) This can't > be different because the shim provided verification protocol > assumes that it's being handed a PE image (hence the need for > Linux to package itself as a fake PE image), and hence can't be > used for verifying other than the Xen and Dom0 kernel binaries. > > > At first I am going to prepare multiboot2 protocol implementation for Xen > > (there > > is about 80% of code ready) with above mentioned workaround. > > Is that really worthwhile as long as it's not clear whether ... > > > Later I am going to work on multiboot2efi module. > > ... is going to be accepted? > > > What do you think about that? > > Any comments, suggestions, objections? > > The complications here make it pretty clear to me that the > GrUB2-less solution (or, if GruB2 absolutely has to be involved, > its chain loading capability) I have been advocating continues > to be the better (and, as said before, conceptually correct) > model. However my understanding is that the general distro approach is to use GRUB2 and I think we want to follow the mainstream on this. Which means using GRUB2 and making sense of the myrid of patches that each distro has.