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.
> > 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.
--
Colin Watson [cjwatson@ubuntu.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
