[Bug 1954683] Re: grub is missing secure boot support for compressed kernels (our arm64 kernels)

[Julian Andres Klode]

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
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954683

Title:
  grub is missing secure boot support for compressed kernels (our arm64
  kernels)

Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Fix Committed
Status in grub2 source package in Impish:
  Won't Fix
Status in grub2 source package in Jammy:
  Fix Released

Bug description:
  [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)
  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).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1954683/+subscriptions