[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



[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.


Reply to: