RFC: Use dpkg triggers to reinstall EFI GRUB upon signed grub or shim change

Pascal Hambourg pascal at plouf.fr.eu.org
Sun Jul 23 15:24:26 BST 2023


[Note: This text mentions only amd64 packages for clarity and brevity 
(*cough*), but I guess most of it also applies to arm64 and i386/ia32]

Dear GRUB and shim maintainers,

*Background*

grub-efi-amd64 postinst script runs grub-install to reinstall the boot 
loader upon package install or upgrade.
grub-install takes GRUB signed image grubx64.efi.signed (provided by 
grub-efi-amd64-signed) if available.
grub-install takes shim files shimx64.efi.signed fbx64.efi.signed 
mmx64.efi.signed BOOTX64.CSV (provided by shim-signed, 
shim-helpers-amd64-signed and shim-unsigned) if grubx64.efi.signed and 
shimx64.efi.signed are available.

This is reflected in the package dependency tree:

grub-efi-amd64
depends: grub-efi-amd64-bin
  recommends: grub-efi-amd64-signed (grubx64.efi.signed)
   recommends: shim-signed (shimx64.efi.signed)
    depends: grub-efi-amd64-bin
    depends: grub2-common (grub-install)
    depends: shim-signed-common (update-secureboot-policy)
    depends: shim-helpers-amd64-signed (fbx64.efi.signed mmx64.efi.signed
     depends: shim-unsigned (BOOTX64.CSV)

grub-efi-amd64 package description states "Installing this package 
indicates that this version of GRUB should be the active boot loader", 
which I read as "other packages should not run grub-install if this 
package is not installed". However, shim-signed and 
shim-helpers-amd64-signed maintainer scripts also run grub-install even 
if grub-efi-amd64 is not installed. Although this implementation has 
worked fairly well in the standard use case, it comes in the way of edge 
cases and has several shortcomings:
- grub-install may be run by maintainer scripts even if grub-efi-amd64 
is not installed.
- shim-signed and shim-helpers-amd64-signed maintainer scripts duplicate 
parts of grub-efi-amd64 postinst. These parts should be kept in sync but 
they are currently out of sync.
- grub-install may be run needlessly or multiple times during a package 
processing batch.
- grub-efi-amd64-signed has no maintainer scripts, so its installation, 
upgrade or removal does not run grub-install.
- shim-signed depends on grub packages.
(non-exhaustive list)


*Proposal*

I propose to use triggers upon signed grub and shim package change in 
order to run grub-install (and possibly ESP cleanup) only in 
grub-efi-amd64 postinst instead of shim-* maintainer scripts. If this 
proposal receives positive feedback, I volunteer to write and submit a 
more detailed specification, then work on its implementation.

Benefits:
- run grub-install only if grub-efi-amd64 is installed
- avoid duplicating maintainer scripts and keeping them in sync
- run grub-install at most once per package processing batch
- allow to run grub-install only when needed (e.g. shim changes are 
irrelevant if grub-efi-amd64-signed is not installed)
- remove shim-signed dependency on grub packages
- fix other shortcomings

Additional goals:
- clarify ESP (EFI System Partition) cleanup policy
- allow use of shim with other boot loaders than GRUB
- prepare support for multi-arch secure boot with 32 and 64-bit x86 UEFI

Note: grub-cloud-amd64 is a special case which already uses triggers on 
grub and shim directories to run grub-install. It is out of the scope of 
this proposal and should not be affected.


*Clarify ESP cleanup policy*

Currently, shim-signed postrm deletes shimx64.efi from the ESP target 
directory /boot/efi/EFI/$bootloader_id.
shim-helpers-amd64-signed postrm deletes fbx64.efi and mmx64.efi from 
the ESP target directory.
BOOTX64.CSV is not deleted from the ESP even though it points to deleted 
shimx64.efi.
shim files are not deleted from the ESP removable media path 
(/boot/efi/EFI/BOOT) even if debconf item 
grub2/force_efi_extra_removable is set to true.

I believe it would be best if grub-install did ESP cleanup on its own. 
Meanwhile, what grub-efi-amd64 postinst should do is an open point:
- delete all shim files (shimx64.efi fbx64.efi mmx64.efi BOOTX64.CSV) 
from the ESP target directory if source files are not installed ?
- always delete shim files from the ESP target directory before running 
grub-install ? what if grub-install fails ?
- also delete shim files from the ESP removable media path if 
grub2/force_efi_extra_removable=true ?
- or do no ESP cleanup at all ?
- other ?

In any case, if GRUB and shim files are installed into the ESP by 
grub-efi-amd64 only, then ESP cleanup should not be done by other packages.


*Allow use of shim with other boot loaders than GRUB*

(E.g. systemd-boot, cf. bug #1039058)
shim packages should not depend on any grub packages.
shim packages should not use any grub-specific triggers.


*Prepare support for multi-arch secure boot with 32 and 64-bit x86 UEFI*

(My use case for this is to install a regular Debian amd64 system on a 
removable disk and make it bootable on both 32 and 64-bit UEFI with 
secure boot (and BIOS), just like amd64 installation and live images. 
This is not currently possible because of grub and shim package conflicts.)

grub-efi-* and shim-* packages for a given EFI architecture should not 
share any triggers with another EFI architecture.
shim-unsigned control file should have "Multi-Arch: same" (like 
shim-signed) so that packages of different architectures can be 
installed together.

Thanks for reading me and thanks in advance for your comments.



More information about the Pkg-grub-devel mailing list