linux-kernel - Re: EFI and multiboot2 devlopment work for Xen

Open Source and information security mailing list archives

Message-ID: <5266A6AD.90004@gmail.com>
Date:	Tue, 22 Oct 2013 18:24:13 +0200
From:	Vladimir 'φ-coder/phcoder' Serbinenko 
	<phcoder@...il.com>
To:	The development of GNU GRUB <grub-devel@....org>
CC:	Daniel Kiper <daniel.kiper@...cle.com>,
	"Woodhouse, David" <david.woodhouse@...el.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"keir@....org" <keir@....org>,
	Ian Campbell <ian.campbell@...rix.com>,
	"stefano.stabellini@...citrix.com" <stefano.stabellini@...citrix.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	Jan Beulich <JBeulich@...e.com>,
	"ross.philipson@...rix.com" <ross.philipson@...rix.com>,
	"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
	"Maliszewski, Richard L" <richard.l.maliszewski@...el.com>
Subject: Re: EFI and multiboot2 devlopment work for Xen

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@....org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Download attachment "signature.asc" of type "application/pgp-signature" (292 bytes)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives