Tuesday, 1 December 2015

Re: Xenial/grub2: Changes for Xen

Version: GnuPG v2.0.22 (GNU/Linux)

On 01.12.2015 12:11, Colin Watson wrote:
> On Tue, Dec 01, 2015 at 09:49:55AM +0100, Stefan Bader wrote:
>> On 30.11.2015 18:22, Mathieu Trudel-Lapierre wrote:
>>> On Mon, Nov 30, 2015 at 10:01 AM, Stefan Bader <[email protected]
>>> <mailto:[email protected]>> 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),
> We already have GRUB_CMDLINE_XEN; no need for a separate file.

Just a quick answer on that ^. Yes, that option is processed (as the 3 other
variations related). But /etc/default/grub contains no examples. And imo it
should not as nobody not using Xen would care. That is the reason I added the
additional config file which will be sourced in automatically when update-grub
is called.

>>> 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.
> It's been suggested before, and the current situation is certainly
> unfortunate, but this really needs to be sorted out upstream
> ([email protected]).
> Also, moving the conffile around is a cumbersome way to do this
> ordering; if somebody wants to move it back then they won't get any
> updates to the generator script, so it's anything but "simple" to make
> this change in practice, unfortunately. I've long thought that this is
> an indication that the entire configuration system needs to be
> rethought.
>>> 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).
> It would be reasonable to emit the Xen EFI image as another thing to be
> signed, but how would further signature chaining work after that?
> No need for a different key just because it's in universe. The archive
> key is for the archive, not just for main. We force all signature
> requests into unapproved for manual attention by archive admins so that
> random packages can't get signatures.