[Git-commits] [grml/grml-live] c5af17: Refresh Secure Boot support, supporting new 'debia...

[Michael Prokop]

  Branch: refs/heads/mika/secureboot-working
  Home:   https://github.com/grml/grml-live
  Commit: c5af178f9fe777ce51ea3b1490cd96ac9c6fa6c8
      https://github.com/grml/grml-live/commit/c5af178f9fe777ce51ea3b1490cd96ac9c6fa6c8
  Author: Michael Prokop <mika at grml.org>
  Date:   2020-06-18 (Thu, 18 Jun 2020)

  Changed paths:
    M etc/grml/grml-live.conf
    M grml-live
    R templates/EFI/BOOT/README
    R templates/EFI/BOOT/grubx64.efi.signed
    R templates/EFI/BOOT/shimx64.efi.signed
    A templates/EFI/debian/BOOT/README
    A templates/EFI/debian/BOOT/grubx64.efi.signed
    A templates/EFI/debian/BOOT/shimx64.efi.signed
    A templates/EFI/ubuntu/BOOT/README
    A templates/EFI/ubuntu/BOOT/grubx64.efi.signed
    A templates/EFI/ubuntu/BOOT/shimx64.efi.signed
    R templates/boot/grub/grmlenv.cfg
    M templates/secureboot/grub.cfg

  Log Message:
  -----------
  Refresh Secure Boot support, supporting new 'debian' method

Secure Boot mode wasn't reliably working (e.g. failing to boot in EFI
mode without Secure Boot being present) and hard to debug.

Now with our move from our own Grml kernel packages to the official
Debian kernel ones (which are signed and intended for usage with enabled
Secure Boot) it makes sense to support a proper Secure Boot chain
without hacks like we used (relying on and old GRUB binary from Ubuntu
which supported booting unsigned kernels).

We do NOT enable Secure Boot support by default *yet* though, since we
need to get more testing of this and we're in the middle between an RC
version (2020.06-rc1) and the upcoming new stable version of Grml.

Relevant changes:

* minimize templates/secureboot/grub.cfg: while it's certainly nice
  to display only the entries that are actually working under Secure Boot,
  it's annoying to have to maintain yet another place of boot menus.
  Also if something fails with detection of Secure Boot then it's annoying
  to have to debug this, instead let's display an error message and inform
  the user about it and ask for debugging information

* move templates/EFI/BOOT towards templates/EFI/ubuntu/BOOT/ to be able
  to support debian and ubuntu methods at the same time

* ship GRUB binaries in templates/EFI/debian/, similar to the ones in
  templates/EFI/ubuntu

* switch Ubuntu's grubx64.efi.signed from grubx64.efi.signed to gcdx64.efi.signed;
  they differ in what GRUB's $prefix variable is set to:
  * gcdx64.efi.signed uses boot/grub/
  * grubx64.efi.signed uses EFI/ubuntu/
  -> the code in grml-live itself was adjusted accordingly and this also
  enables us to generalize the Secure Boot methods debian + ubuntu to
  use the same code path

* drop templates/boot/grub/grmlenv.cfg: depending on the GRUB version
  being used the behavior is different and we switched from cpuid to
  probe in the past already, while even probe isn't always reliable
  to identify whether we're running under Secure Boot or not.
  This is non-obvious and hard to debug and also adds another
  indirection, so let's get rid of grmlenv.cfg.

  FTR, instead of "if probe ; then ..." we could check for the
  the return code using "probe; if [ $? = 30 ]; then"... when running
  under Secure Boot, since loading additional modules is forbidden there
  and will return with exit code 30 then. This behavior depends on
  the GRUB version though, so if at all this needs to be handled in
  custom templates.

* mention secure boot method in execution prompt/summary

* update etc/grml/grml-live.conf to properly reflect current state of
  Secure Boot support

This work was funded by Grml-Forensic.