Re: RFC: Use dpkg triggers to reinstall EFI GRUB upon signed grub or shim change
On Sun, Jul 23, 2023 at 04:06:53PM +0200, Pascal Hambourg wrote:
> [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]
Curious why it says July 23, I'm sure I received this like last week. I
think I explained what I'm looking for in the trigger approach back
then, namely we need to guarantee that things work correctly without
grub-efi-amd64 installed, as shim itself is calling grub-install now,
and it works without grub-efi-amd64 installed (and in fact, we do not
have co-installability for grub-efi-amd64 and grub-pc so far, hence
Ubuntu co-installs grub-efi-amd64-signed and grub-pc).
Anyway I'm off work until Jan 8th, so I won't spend time reading this
in great detail as I have non-work-adjacent things I promised to take
care of over the break like the keepassxc update.
>
> 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
We need to continue running grub-install without that installed, if
just -signed is installed too. We also want to pivot to only
shipping monolithic images by default if possible, avoiding
efi-amd64-bin (and hence not needing efi-amd64, maybe?).
Otherwise we end up breaking existing systems.
>
>
> *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.
I believe the ESP shall not be cleaned up under any circumstances, even
when the package(s) are being purged. The ESP is not operated by the
package manager, and it's one of the most risky things to do.
>
>
> *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.
(putting on my shim-review hat)
Signing requests for shims trusting systemd-boot will likely be accepted
by shim-review board later in January when we merge the systemd-boot
questions.
>
>
> *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.
(putting on solely my debian hat)
We plan to drop 32-bit signed binaries now, so this is out of scope, the
i386 signed kernels are gone already.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: