Re: EFI and multiboot2 devlopment work for Xen

[Michael Chang]

2013/10/23 Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>:
> 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.

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@xxxxxxxxx                              Intel Corporation
>>
>>
>>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@xxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/