2013/10/23 Michael Chang <mch...@suse.com>: > 2013/10/23 Konrad Rzeszutek Wilk <konrad.w...@oracle.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.woodho...@intel.com Intel Corporation >>> >>> >>> >> >> >> >> _______________________________________________ >> Grub-devel mailing list >> grub-de...@gnu.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/