Instructions updated as I accidentally wrote to upgrade grub-efi-
arm64-signed, but duh, it's grub{2,}-common you want to upgrade from
proposed.** Description changed: [Impact] arm64 systems currently cannot have their grub updated when booted in secure boot mode, despite booting fine, as the postinst runs grub-check-signatures and grub-check-signatures does not handle the compressed kernels used on arm64. It seems the cloud images only ship unsigned grub at the moment, but there may be other images shipping signed boot stack that customers would expect to work (and then fail during a grub update) and we can also consider this hardware enablement of arm64 secure boot. [Attack plan] 1. Modify grub-check-signatures to optionally decompress kernels before passing them to sbverify 2. Modify grub to either a) verify after decompress b) disable shim_lock verifier on arm64, and only use the rhboot We do not know if this is a long-term solution, we really should migrate back to kernels that are proper EFI executables themselves such that we can use standard EFI functions to run them as well. [Test plan] 1. Grab an arm64 cloud image 2. Boot in qemu, WITHOUT SECURE BOOT (AAVMF_VARS.fd): Install grub-efi-arm64-signed shim-signed if not already installed 3. Reboot in secure mode (using AAVMF_VARS.ms.fd) 4. See that the system boots 5. apt install --reinstall grub-efi-arm64-signed, observe failure message about unsigned kernels - 6. apt install grub-efi-arm64-signed/focal-proposed, observe success + 6. apt install ?installed?source-package((^grub2$)/focal-proposed (aka grub2-common grub-common), observe success when reinstalling grub-efi-arm64-signed. 6. Install another signed kernel, observe success (*) shim/grub may need to be launched manually in qemu as MS variables place the EFI shell first in the boot order, select the boot entry for the disk from the interrupt menu, or do FS0:, followed by \EFI\BOOT\BOOTAA64.EFI in the EFI shell to launch it. (*) Surprisingly maybe, kernel upgrades are not affected as they do not call grub-check-signatures, so installing an unsigned kernel still succeeds, however, this is not a regression from this patch. [Where problems could occur] We only modify the grub-check-signatures script in the SRU to add decompression. This could change the behavior of the script, and introduce new bugs that cause false positives or false negatives. [Other info: Impact; 2.06-only, not relevant for SRU] In 2.06, the verifiers framework runs before any decompression, causing the kernels to fail verification, as it tries to verify the compressed data. In grub 2.04, we manually verified the file after we had opened it (hence after all filters). ** Description changed: [Impact] arm64 systems currently cannot have their grub updated when booted in secure boot mode, despite booting fine, as the postinst runs grub-check-signatures and grub-check-signatures does not handle the compressed kernels used on arm64. It seems the cloud images only ship unsigned grub at the moment, but there may be other images shipping signed boot stack that customers would expect to work (and then fail during a grub update) and we can also consider this hardware enablement of arm64 secure boot. [Attack plan] 1. Modify grub-check-signatures to optionally decompress kernels before passing them to sbverify 2. Modify grub to either a) verify after decompress b) disable shim_lock verifier on arm64, and only use the rhboot We do not know if this is a long-term solution, we really should migrate back to kernels that are proper EFI executables themselves such that we can use standard EFI functions to run them as well. [Test plan] 1. Grab an arm64 cloud image 2. Boot in qemu, WITHOUT SECURE BOOT (AAVMF_VARS.fd): Install grub-efi-arm64-signed shim-signed if not already installed 3. Reboot in secure mode (using AAVMF_VARS.ms.fd) 4. See that the system boots 5. apt install --reinstall grub-efi-arm64-signed, observe failure message about unsigned kernels - 6. apt install ?installed?source-package((^grub2$)/focal-proposed (aka grub2-common grub-common), observe success when reinstalling grub-efi-arm64-signed. - 6. Install another signed kernel, observe success (*) + 6. apt install ?installed?source-package((^grub2$)/focal-proposed (aka grub2-common grub-common) + 7. observe success when reinstalling grub-efi-arm64-signed. + 8. Install another signed kernel, observe success (*) shim/grub may need to be launched manually in qemu as MS variables place the EFI shell first in the boot order, select the boot entry for the disk from the interrupt menu, or do FS0:, followed by \EFI\BOOT\BOOTAA64.EFI in the EFI shell to launch it. (*) Surprisingly maybe, kernel upgrades are not affected as they do not call grub-check-signatures, so installing an unsigned kernel still succeeds, however, this is not a regression from this patch. [Where problems could occur] We only modify the grub-check-signatures script in the SRU to add decompression. This could change the behavior of the script, and introduce new bugs that cause false positives or false negatives. [Other info: Impact; 2.06-only, not relevant for SRU] In 2.06, the verifiers framework runs before any decompression, causing the kernels to fail verification, as it tries to verify the compressed data. In grub 2.04, we manually verified the file after we had opened it (hence after all filters). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1954683 Title: grub is missing secure boot support for compressed kernels (our arm64 kernels) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1954683/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
