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

Open Source and information security mailing list archives

Date:	Wed, 23 Oct 2013 14:51:10 +0800
From:	Michael Chang <mchang@...e.com>
To:	The development of GNU GRUB <grub-devel@....org>
Cc:	"Woodhouse, David" <david.woodhouse@...el.com>,
	"keir@....org" <keir@....org>,
	Ian Campbell <ian.campbell@...rix.com>,
	"stefano.stabellini@...citrix.com" <stefano.stabellini@...citrix.com>,
	Daniel Kiper <daniel.kiper@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ross.philipson@...rix.com" <ross.philipson@...rix.com>,
	Jan Beulich <JBeulich@...e.com>,
	"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	"Maliszewski, Richard L" <richard.l.maliszewski@...el.com>
Subject: Re: EFI and multiboot2 devlopment work for Xen

2013/10/23 Michael Chang <mchang@...e.com>:
> 2013/10/23 Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>:
>> On Tue, Oct 22, 2013 at 03:25:39PM +0000, Woodhouse, David wrote:
>>> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>>> >
>>> > And looking at bit deeper in the x86/linux boot spec:
>>> >
>>> > **** EFI HANDOVER PROTOCOL
>>> >
>>> > This protocol allows boot loaders to defer initialisation to the EFI
>>> > boot stub. The boot loader is required to load the kernel/initrd(s)
>>> > from the boot media and jump to the EFI handover protocol entry point
>>> > which is hdr->handover_offset bytes from the beginning of
>>> > startup_{32,64}.
>>>
>>> Oh, ignore that. You want the *actual* PE executable entry point, as it
>>> would get invoked by a real UEFI firmware.
>>
>> Right. The Xen hypervisor can be built in two images: a standard PE/COFF
>> that can be executed from the EFI shell, and an multiboot blob that can
>> be loaded by multiboot compatible boot loaders (like GRUB).
>>
>>>
>>> I thought that's what Grub invoked, for 'linuxefi'. Perhaps I mean a
>>> chainloader method of some kind instead. Either way, make Grub (or
>>> whatever bootloader you choose) load it as an EFI executable.
>>
>> Looks like chainloader was it from Peter's answer. But then you can't
>> do SecureBoot <sigh>.
>
> In SUSE/openSUSE we had a patch[1] in chainloader for supporting
> shim's protocol to verify loaded EFI images. The efi image can be
> loaded and verified by db or MOK keyrings.
>
> [1] https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-secureboot-chainloader.patch?expand=1
>
> With the linux foundation's PreLoader, that patch can be eliminated
> totally as the verification is done via installed hook, where
> verification result from MOK keyring is added, to authenticate file
> protocol. The verification is thus transparent to UEFI applications so
> any other loader, like shim, can be benefited from it.

Sorry, other loaders should be gummiboot, refind and so on ..

>
> The PreLoader has it's own controversy as that protocol is not part of
> UEFI spec, instead it's part of PI spec for UEFI firmware
> implementation thus shouldn't be used by an application (loader). It
> could have compatibility problem ...
>
> Regards,
> Michael
>>
>>>
>>> Seriously, forget Grub for now. Grub is mostly just an exercise in
>>> gratuitously doing things the difficult way and wondering why it's
>>> fragile.
>>>
>>> Make your code work as an EFI executable when loaded directly from the
>>> UEFI firmware. Worry about the insanity of grub later.
>>
>> That has been done by Jan. Now we are at the 'have a shim that launches
>> GRUB2, now what?'
>>
>>>
>>>
>>> --
>>>                    Sent with MeeGo's ActiveSync support.
>>>
>>> David Woodhouse                            Open Source Technology Centre
>>> David.Woodhouse@...el.com                              Intel Corporation
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@....org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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