On Mon, Nov 30, 2015 at 10:01 AM, Stefan Bader <stefan.ba...@canonical.com> wrote: [...]
> Currently I do a /etc/grub.d/xen.cfg which, apart from adding a nicely > separated > place for Xen specific grub options (which I think is worth keeping), adds > an > override string to boot into Xen by default. A better way for that long > term > seems to be to simply change the order of the generator script > (/etc/grub.d/20_linux_xen). This only generates a real section if there is > a Xen > hypervisor installed and doing that a user likely also wants that to > become the > default. So the question is whether it sounds reasonable to rename > 20_linux_xen > into something like 09_xen? > I'm not opposed to that, but it's worth checking with the Debian GRUB maintainers too, since we usually try to keep grub in sync. > The the other thing probably needs more change than only grub: For a while > now > xen-hypervisor ships a version that is normally used from grub (using > multiboot) > and an EFI executable. The normal version cannot be used on UEFI systems > because > multiboot protocol has some shortcomings and there is no way to transfer > control > in a way to allow to get the memory layout (as one example). > Currently 20_linux_xen generates two grub entries, one for xen-*.gz and > one for > xen-*.efi. The latter plainly is wrong and has only gone unnoticed because > the > former is selected by default. But I would propose the following change: > We most likely don't want to use the .efi image at all, if we want to maintain the behavior of simply booting via grub for both methods. One use of the .efi image is probably because you can more easily enforce the signature on that EFI binary, but it doesn't seem to me like something we'd go out of our way to sign anyway. [...] > > As for the question on how to handle UEFI boot, I don't know what can be > done > about that. The *.efi executable likely needs to be rather loaded directly > from > the shim layer, and then sooner than later also needs to become signed. Or > As above, I think we'd probably just keep using the kernels loaded from grub. On top of not requiring the separate signature of another EFI image (and either that signature coming from Microsoft or chainloading from shim and changing the EFI boot entries to account for that), it would have the advantage of already working, being the same for both the EFI and legacy BIOS cases. We also already sign at least the standard shipping kernel. Signing the Xen bits may require a bit of work though, since it's in universe and we may want to sign it with a different key. At least for now, you'll still benefit from the bootloader being signed, just like it is in the non-Xen case. that would allow using the normal grub2->xen chain for the UEFI boot case. > But I > am not sure there is an outtcome, yet. So I guess for now the primary > target > would be to ignore the *.efi file when generating the grub.cfg. > I don't know enough about Xen to know why the normal loading using grub2 would behave differently in UEFI (as you can no doubt notice above), but yes, the short answer IMO is that we should just ignore the .efi file. Regards, Mathieu Trudel-Lapierre <mathieu...@ubuntu.com> Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C 80D3 C7DA A946 DC95 CA5A
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
