On Mon, Nov 30, 2015 at 10:01 AM, Stefan Bader <email@example.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,