Re: EFI and multiboot2 devlopment work for Xen - Vladimir 'φ-coder/phcoder' Serbinenko

From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	"keir@xen.org" <keir@xen.org>,
	"Woodhouse, David" <david.woodhouse@intel.com>,
	"stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"ross.philipson@citrix.com" <ross.philipson@citrix.com>,
	"Maliszewski, Richard L" <richard.l.maliszewski@intel.com>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: EFI and multiboot2 devlopment work for Xen
Date: Tue, 22 Oct 2013 18:24:13 +0200	[thread overview]
Message-ID: <5266A6AD.90004@gmail.com> (raw)
In-Reply-To: <20131022160146.GH3626@debian70-amd64.local.net-space.pl>

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

On 22.10.2013 18:01, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 03:42:42PM +0000, Woodhouse, David wrote:
>> On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>>>
>>> There are two problems with this:
>>>
>>> 1) The kernel will only boot if it's signed with a key in db, not a key
>>> in MOK.
>>> 2) grub will read the kernel, but the kernel will have to read the
>>> initramfs using EFI calls. That means your initramfs must be on a FAT
>>> partition.
>>>
>>> If you're happy with those limitations then just use the chainloader
>>> command. If you're not, use the linuxefi command.
>>
>> Well, we're talking about booting the Xen hypervisor aren't we?
>>
>> So yes, there are reasons the Linux kernel uses the 'boot stub' the way
>> it does, but I'm not sure we advocate that Xen should emulate that in
>> all its 'glory'?
> 
> Right, I think that sensible mixture of multiboot2 protocol (it is needed
> to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot protocol
> for it) with extension proposed by Vladimir and something similar to linuxefi
> command will solve our problem (I proposed it in my first email). Users which
> do not need SB may use upstream GRUB2 and others could use
> 'multiboot2efi extension'.
I think it's possible to handle secureboot with same multiboot2 base.
Correct me if I'm wrong but secureboot doesn't specify format of
signaatures, only that they should be present and checked.
So why not to make that the only difference between secureboot-enabled
and not-secureboot-enabled versions is that former enforces signatures
even against user will. This will reduce the policy-charger patch to
about 100 lines.
The signature format to use can be discussed as well. My main problem
with pe signatures as used for EFI is their apparent complexity but I
haven't looked in them yet.
> 
> Daniel
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]