-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJWXV8zAAoJEOhnXe7L7s6j4s0P/03GKLQXNnScd76Pb2fYJLZW
B5GRto4328JkRB/Q7GqTUr8EfrZNT4Lb4lC33xWtj9ShPrcIF/4u4SBrDwGXhJn1
9J3xx3qoDbK87DNiy6sYUZRAlg4IgaSdV0zMPi7oBOcyZOu+35tNFi/4j5pVcyNl
9fUp2piuV4IbItwt6EFUzBmTKnyVdHXNyagGx8V0WuMBs74TRzwlOauZy77i2maX
EhW7DLyzqGvpvhH1RQwGbiJX2rgSq5S17s57UScu+Va65W/m47Zy+x0NsSGiIz/u
MSdbURh3175ouM9WO7KAbzus/v6NeQA5WLIkaFfF5ALQS5uuL7izq6F+8N6kv+b4
CsrZrDcC76aQ6C3vfS0+U+R/yDn1h7soByJcN3L158m4tpPINIx5T8QcRSQjfMvk
JrVN8vCdwlBcBh+n6FYQpOT3u43ckKiCU9J3JUUJGTfKvLWhlZXkVqcxlAhoXlew
ieSILTIuL5JQvM8irO86Xl94boUlpZ0K8MyjLMKsCSFdpElrSRIxfLhjCQd1Ofz5
mkW+toeBFJA38+oYVMjGEHIpFI6x/OZq0dRiAfXZn7/wsi1/18sZY4aEzWFw1RDy
9mc1h+OmYsfnmlNIv50OMsDlg+fs7hQ3ppFPLwnTI1IfmWIITyAz4jZQBmmESbyo
S0kilyYS9p8GIEYvqu+6
=TCuq
-----END PGP SIGNATURE-----
On 30.11.2015 18:22, Mathieu Trudel-Lapierre wrote:
> On Mon, Nov 30, 2015 at 10:01 AM, Stefan Bader <stefan.bader@canonical.com
> <mailto:stefan.bader@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.
Fair point. I added Colin and Ian. Actually Ian may remember some of the details
about multiboot that I forgot. And maybe it makes sense to reach out to
pkg-xen-devel and if a similar list exists for grub2 to that as well.
>
>
> 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.
I agree. Its also simpler to find the choice between Xen and normal boot there.
So I, too, would prefer any solution that keeps grub as the integration point.
>
> [...]
>
>
> 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.
Right now it would be ok. But there could be the time when the whole boot chain
must be signed while secure boot is on. Which will also suck in the case of
quickly giving people test kernels (but that is kind of a different issue).
But I guess this is a good time to talk together with the Debian side and figure
out a plan for this (and maybe I then have an email archive to fill the holes in
my memory).
>
> 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.
I am not sure I remember it correctly. I think the problem was somewhere around
taking the multiboot route would exit boot services before transferring to the
Xen hypervisor code. And at least one problem there is that E820 has been
replaced by some other mapping which is no longer accessible then.
I have a vague feeling there was also something mentioned about needing to pass
on ... something. But I fail to remember what and why it was not possible with
the existing multiboot protocol.
-Stefan
>
> Regards,
>
> Mathieu Trudel-Lapierre <mathieu-tl@ubuntu.com <mailto:mathieu-tl@ubuntu.com>>
> Freenode: cyphermox, Jabber: mathieu.tl <http://mathieu.tl>@gmail.com
> <http://gmail.com>
> 4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C 80D3 C7DA A946 DC95 CA5A
>
