-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJWXYG1AAoJEOhnXe7L7s6jWSgQAJGx8I15W9Ol2fQXvWKqO0jJ
MEJ1HmHSrWU+NPpU9gNqPnG/BiOQ3pSsH5ZlmHnYJaKDlgTBWPeq2ljJXHg97pVL
ntBlY7ddME2GiU9qcHMzvZhHYIwmE1XxFSIiJuZ54jDHn6hWGlZ4orS6iffipHOH
8tBizDEEgWEnp1HbIc9HPl7hL/oO2W4GMmlIPmt3h8b2aqhKc8IfMPzl2aihfVs1
cBXitoxNnfnWN/1honwhJ03q1S909qiaOuQ7Dg2MUlE1QkoPjp/KfgoPWuTeQSTr
7ze5/nGv8PtBdZACqMsDak3wxvOTntcnfUXPeCr3PoNqQyKQO4+7eEmhh9HIL5yD
BP0j5RrPomfERvmJsl/zLLibEUTGekztlBCQ+7DOi9UADjTdoXAJqaYS+zUE1fKo
leGCGydiJcIBXzK6u6qE1DEUivqoazTZcG5NqPHbuxkOPPB/vo8wOyY6ajX1CFge
zOljyjWP9mef1NMuOI5ZveVtI5o+2FykGQw1vlxiYjuDapa+2f4U40xtAkerHtP8
VoHqR2lumeEgOq7KlDGAvfLC9PU22OuKbferBjmEgPmFyj42BJShj5V9JtKzKTzW
xVkli68MSHYsfx/PCHprSI2C97+sdtuGYM9xd7fIWIEESs3yoNGSMiXo8rulsSKJ
bdVuXVvAWqdCib9lbyIR
=SJm3
-----END PGP SIGNATURE-----
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 <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),
>
> 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
> (grub-devel@gnu.org).
>
> 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.
>
