[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
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 >> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |