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. >
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
