| 2021-12-13 17:09:51 |
Julian Andres Klode |
bug |
|
|
added bug |
| 2021-12-13 17:10:00 |
Julian Andres Klode |
bug task added |
|
grub2 (Ubuntu) |
|
| 2021-12-13 17:10:09 |
Julian Andres Klode |
bug task deleted |
grub2 (Ubuntu) |
|
|
| 2021-12-13 17:10:18 |
Julian Andres Klode |
tags |
|
regression-proposed |
|
| 2021-12-14 19:46:29 |
Brian Murray |
tags |
regression-proposed |
regression-proposed rls-jj-incoming |
|
| 2021-12-15 15:27:13 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Impish |
|
| 2021-12-15 15:27:13 |
Julian Andres Klode |
bug task added |
|
grub2-unsigned (Ubuntu Impish) |
|
| 2021-12-15 15:27:13 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Focal |
|
| 2021-12-15 15:27:13 |
Julian Andres Klode |
bug task added |
|
grub2-unsigned (Ubuntu Focal) |
|
| 2021-12-15 15:27:13 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Jammy |
|
| 2021-12-15 15:27:13 |
Julian Andres Klode |
bug task added |
|
grub2-unsigned (Ubuntu Jammy) |
|
| 2021-12-16 16:20:54 |
Matthieu Clemenceau |
tags |
regression-proposed rls-jj-incoming |
fr-1931 regression-proposed rls-jj-incoming |
|
| 2021-12-16 18:32:56 |
Brian Murray |
tags |
fr-1931 regression-proposed rls-jj-incoming |
fr-1931 regression-proposed |
|
| 2021-12-17 15:48:18 |
Julian Andres Klode |
summary |
grub is missing secure boot support for compressed kernels |
grub is missing secure boot support for compressed kernels (our arm64 kernels) |
|
| 2022-01-10 14:44:20 |
Julian Andres Klode |
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
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).
[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]
TBD
[Where problems could occur]
TBD |
[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
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. |
|
| 2022-01-10 14:44:28 |
Julian Andres Klode |
grub2-unsigned (Ubuntu Jammy): status |
New |
Fix Committed |
|
| 2022-01-10 14:45:19 |
Julian Andres Klode |
affects |
grub2-unsigned (Ubuntu Focal) |
grub2 (Ubuntu Focal) |
|
| 2022-01-11 15:01:42 |
Julian Andres Klode |
grub2 (Ubuntu Focal): status |
New |
In Progress |
|
| 2022-01-11 15:02:12 |
Julian Andres Klode |
grub2 (Ubuntu Impish): status |
New |
Won't Fix |
|
| 2022-01-11 16:13:55 |
Julian Andres Klode |
grub2 (Ubuntu Impish): status |
Won't Fix |
Triaged |
|
| 2022-01-12 18:11:11 |
Launchpad Janitor |
grub2 (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-01-26 14:18:46 |
Julian Andres Klode |
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
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. |
[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
[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. |
|
| 2022-01-26 14:19:39 |
Julian Andres Klode |
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
[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. |
[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. |
|
| 2022-01-26 15:35:02 |
Robie Basak |
grub2 (Ubuntu Focal): status |
In Progress |
Incomplete |
|
| 2022-02-16 16:30:44 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/415681 |
|
| 2022-02-16 16:30:44 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/415682 |
|
| 2022-02-17 09:46:21 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~xypron/grub/+git/grub/+merge/415724 |
|
| 2022-03-15 15:28:11 |
Julian Andres Klode |
grub2 (Ubuntu Impish): status |
Triaged |
Won't Fix |
|
| 2022-03-15 15:34:37 |
Julian Andres Klode |
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. |
[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. 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). |
|
| 2022-03-15 15:34:48 |
Julian Andres Klode |
grub2 (Ubuntu Focal): status |
Incomplete |
In Progress |
|
| 2022-03-22 08:43:13 |
Łukasz Zemczak |
grub2 (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2022-03-22 08:43:15 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-03-22 08:43:16 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2022-03-22 08:43:19 |
Łukasz Zemczak |
tags |
fr-1931 regression-proposed |
fr-1931 regression-proposed verification-needed verification-needed-focal |
|
| 2022-03-22 11:49:07 |
Julian Andres Klode |
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 grub-efi-arm64-signed/focal-proposed, observe success
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). |
[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 (*)
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). |
|
| 2022-03-22 11:53:38 |
Julian Andres Klode |
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), 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). |
[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). |
|
| 2022-03-22 13:04:59 |
Julian Andres Klode |
tags |
fr-1931 regression-proposed verification-needed verification-needed-focal |
fr-1931 regression-proposed verification-done verification-done-focal |
|
| 2022-04-04 07:18:31 |
Launchpad Janitor |
grub2 (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2022-04-04 07:18:41 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-02-01 09:19:32 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Bionic |
|
| 2023-02-01 09:19:32 |
Julian Andres Klode |
bug task added |
|
grub2 (Ubuntu Bionic) |
|
| 2023-02-01 09:20:21 |
Launchpad Janitor |
grub2 (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2023-02-01 09:20:43 |
Julian Andres Klode |
grub2 (Ubuntu Bionic): status |
Confirmed |
Triaged |
|
| 2023-02-01 17:49:56 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~juliank/grub/+git/bionic/+merge/436705 |
|
| 2023-03-04 07:16:09 |
Steve Langasek |
grub2 (Ubuntu Bionic): status |
Triaged |
Fix Committed |
|
| 2023-03-04 07:16:12 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-03-04 07:16:16 |
Steve Langasek |
tags |
fr-1931 regression-proposed verification-done verification-done-focal |
fr-1931 regression-proposed verification-done-focal verification-needed verification-needed-bionic |
|
| 2023-03-05 20:47:10 |
dann frazier |
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). |
[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]
= focal =
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
2b) On bionic, install linux-virtual-hwe-18.04 and reboot (the LTS kernel in bionic is not signed on arm64)
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). |
|
| 2023-03-05 22:52:22 |
dann frazier |
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]
= focal =
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
2b) On bionic, install linux-virtual-hwe-18.04 and reboot (the LTS kernel in bionic is not signed on arm64)
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). |
[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]
= focal =
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
2b) On bionic, install linux-virtual-hwe-18.04 and reboot (the LTS kernel in bionic is not signed on arm64)
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$)/<series>-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). |
|
| 2023-03-05 22:53:40 |
dann frazier |
tags |
fr-1931 regression-proposed verification-done-focal verification-needed verification-needed-bionic |
fr-1931 regression-proposed verification-done verification-done-bionic verification-done-focal |
|
| 2023-05-30 09:02:40 |
Launchpad Janitor |
grub2 (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2024-02-12 14:23:41 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~mkukri/grub/+git/grub/+merge/459698 |
|
| 2024-02-12 14:24:37 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~mkukri/grub/+git/grub/+merge/459698 |
|
|
