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

[Michael Prokop]

  Branch: refs/heads/master
  Home:   https://github.com/grml/grml-live
  Commit: 518eb395d8652ccf260e4fe6fc15af7946fc7c49
      https://github.com/grml/grml-live/commit/518eb395d8652ccf260e4fe6fc15af7946fc7c49
  Author: Michael Prokop <mika at grml.org>
  Date:   2020-06-19 (Fri, 19 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
    A templates/boot/grub/grml-theme/sb-theme.txt
    M templates/boot/grub/grml-theme/theme.txt
    R templates/boot/grub/grmlenv.cfg
    M templates/boot/grub/header.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 with disabled Secure Boot, but also 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 to do (like 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 right now we're in the middle of 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 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, inform
  the user about it and ask for debugging information.

  Instead introduce a new GRUB theme (/boot/grub/grml-theme/sb-theme.txt)
  which displays a message that we're running in Secure Boot mode.
  While at it, unify indention in existing /boot/grub/grml-theme/theme.txt.

* 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: everything what's relevant
  can be taken care of from inside templates/secureboot/grub.cfg,
  so let's avoid another indirection.

  We also moved the detection of Secure Boot into templates/secureboot/grub.cfg
  and reworked it: while Ubuntu's patches have a C function grub_efi_secure_boot(),
  there's no ready-to-use way to detect Secure Boot. But the wrmsr
  command is amongst the list of GRUB's disabled_mods and we can
  distingiush between exit code 18 (wrong invocation/argument usage) and 30 (Secure Boot forbits loading module).

* mention secure boot method in execution prompt/summary to be aware of
  its (non) presence ahead of execution

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

Thanks: Jordan Uggla for feedback

This work was funded by Grml-Forensic.