On Mon, 2018-04-16 at 17:16 +0200, Philipp Hahn wrote: > Hello, > > Am 15.04.2018 um 23:03 schrieb Steve McIntyre: > > On Thu, Apr 12, 2018 at 05:10:38PM +0100, Luca Boccassi wrote: > > > On Thu, 2018-04-12 at 15:58 +0100, Steve McIntyre wrote: > > > > [ Note cc to the d-efi list. SB is finally in progress after > > > > last > > > > week's sprint! ] > > > > > > > > Very belated, it's time we discussed this. > > ... > > > > This looks like one way of doing this. Philipp Hahn is > > > > suggesting > > > > that > > > > we just don't include the "linux" module in our signed grub > > > > build. That's simpler, but potentially causes problems > > > > elsewhere, > > > > e.g. "it gets a bit nasty to try and dynamically switch between > > > > linux > > > > and linuxefi in live-build". So, let's discuss - we need to > > > > agree our > > > > policy and decide the best mechanism here. Go...! > > > > > > The issues I see is that until now pretty much everywhere "linux" > > > is > > > used in grub.cfg. > > > > > > This can be solved easily, and indeed Philipp has already done > > > it, for > > > local installations - the problems arise when building images. > > > > > > At least in live-build (not sure about debootstrap/live- > > > wrapper?), > > > users can provide their own grub.cfg. Personally I've never seen > > > anyone > > > use anything but "linux" in the menuentry (eg: Kali [2]). > > > > > > So I'd need to do something like this [1] in live-build: > > > > > > sed -i "s|linux\(\s\+/\w\+/vmlinuz\)|linuxefi\1|" \ > > > binary/boot/grub/grub.cfg > > > sed -i "s|initrd\(\s\+/\w\+/initrd\)|initrdefi\1|" \ > > > binary/boot/grub/grub.cfg > > > > > > With the risk of randomly breaking with weird user's grub.cfg :-/ > > > > > > I'd really like to make the process as transparent as possible > > > for > > > users, as there are already enough hoops to jump through as-is to > > > get > > > secure boot working. > > > > > > I have been using the patch from this bug in production for about > > > a > > > year as an alternative in the downstream distro at $work, and it > > > seems > > > to work fine. > > FYI: We (Univention) have been running with "linux" removed for >2 > years. > > > > On the other hand, I imagine it's easier to verify that nothing > > > is > > > broken by removing the "linux" module rather than using this > > > patch. So > > > there's the other side of the coin. > > I see 2 use-cases here: > > 1. make it as easiest as possible to install Debian even on systems > where Secure Boot is enabled by default by providing a signed GRUB > which > loads anything. > > 2. have a more secure setup where everything must be signed. > > We chose to be on the save side and thus removed "linux". But you > patch > seems to be small enough to verify and actually looks quite nice: > With > it both "linux" and "linuxefi" can be used, which has an appeal. > > So I'm okay to switch to your implementation.
Great, thanks! (but please note that the patch is from HPE and the original submitter of this ticket, not myself :-) ) > @steve: I'm currently busy with work and family and don't have that > much > time until next weekend. I havenn't yet checked back for the status > of > the signing box, but how do you want to proceed with GRUB: I haven't > yet > done a complete test build of my patched packages with a self-created > set of key to check that everything work as expected. Shall we > continue > working on my GIT repo or how do you want to get the required changed > in > your repo? > > Thanks in advance and thanks to everyone working on this. > Philipp The Ubuntu folks have quite a lot of additional grub + secureboot patches: https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/patches/series?h=ubuntu What are the chances that efforts could be combined? Otherwise we'll end up facing the same bugs that they already fixed [1]. For what it's worth, I've been shipping our downstream at $work with those patches as well. -- Kind regards, Luca Boccassi [1] I know I have already mentioned it a few times, but those patches include the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1418360 which completely breaks the kernel lockdown functionality.
signature.asc
Description: This is a digitally signed message part
