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

[Julian Andres Klode]

** Description changed:

  [Impact]
  Compressed kernels as we have on arm64 cause grub to fail in two ways:
  
  1. In all versions, grub-check-signatures will fail to verify the
  binaries using sbverify, complain about that in debconf, and then abort
- the installation/upgrade of grub-efi-arm64-signed
+ the installation/upgrade of grub-efi-arm64-signed, kernel and grub
+ upgrades can hence not be installed on secure boot systems.
  
  2. 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).
  
  The rest of the SRU template only refers to point 1, as point 2 only
  applies to the development series jammy.
  
  [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]
  
  On a secure boot ARM64 VM:
  
  1) Run grub-check-signatures to ensure it verifies the kernels
  successfully
  
  [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.

** Description changed:

  [Impact]
  Compressed kernels as we have on arm64 cause grub to fail in two ways:
  
  1. In all versions, grub-check-signatures will fail to verify the
  binaries using sbverify, complain about that in debconf, and then abort
  the installation/upgrade of grub-efi-arm64-signed, kernel and grub
  upgrades can hence not be installed on secure boot systems.
  
  2. 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).
  
  The rest of the SRU template only refers to point 1, as point 2 only
  applies to the development series jammy.
  
  [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]
  
  On a secure boot ARM64 VM:
  
- 1) Run grub-check-signatures to ensure it verifies the kernels
- successfully
+ 1) Run grub-check-signatures to ensure it verifies the kernels successfully
+ 2) Install kernel upgrade and reboot into it
  
  [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.

-- 
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:
  In Progress
Status in grub2 source package in Impish:
  Triaged
Status in grub2 source package in Jammy:
  Fix Released

Bug description:
  [Impact]
  Compressed kernels as we have on arm64 cause grub to fail in two ways:

  1. In all versions, grub-check-signatures will fail to verify the
  binaries using sbverify, complain about that in debconf, and then
  abort the installation/upgrade of grub-efi-arm64-signed, kernel and
  grub upgrades can hence not be installed on secure boot systems.

  2. 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).

  The rest of the SRU template only refers to point 1, as point 2 only
  applies to the development series jammy.

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

  On a secure boot ARM64 VM:

  1) Run grub-check-signatures to ensure it verifies the kernels successfully
  2) Install kernel upgrade and reboot into it

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

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