Re: EFI and multiboot2 devlopment work for Xen

[Michael Chang]

2013/10/23 Michael Chang <mchang@xxxxxxxx>:
> 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.

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@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/