Activity log for bug #2015664

Date Who What changed Old value New value Message
2023-04-09 03:09:42 Steve Langasek bug added bug
2023-04-09 03:09:57 Steve Langasek mokutil (Ubuntu): importance Undecided High
2023-04-09 03:10:01 Steve Langasek tags fr-4055
2023-04-09 03:10:04 Steve Langasek nominated for series Ubuntu Jammy
2023-04-09 03:10:04 Steve Langasek bug task added mokutil (Ubuntu Jammy)
2023-04-09 03:10:04 Steve Langasek nominated for series Ubuntu Focal
2023-04-09 03:10:04 Steve Langasek bug task added mokutil (Ubuntu Focal)
2023-04-09 03:11:03 Steve Langasek mokutil (Ubuntu Focal): importance Undecided High
2023-04-09 03:11:04 Steve Langasek mokutil (Ubuntu Jammy): importance Undecided High
2023-04-25 20:57:37 Nick Rosbrook attachment added SRU test script https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm
2023-04-25 21:00:02 Nick Rosbrook description After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing: $ mkdir test-lp2015664 $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages: $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs: $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script: $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level: $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation: $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu): $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable: $ sudo mokutil --set-verbosity true $ sudo mokutil --set-sbat-policy delete $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted: $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log $ grep -I sbat.c jammy-boot.log sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003 sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable. sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1: $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled: $ mokutil --sb-state SecureBoot enabled Test for Focal: NOTE: This test is the same as Jammy, except that we use the 20.04.5 ISO instead of the 20.04.5 ISO. * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level: $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 20.04.5 ISO, and observe the secureboot violation: $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso * Disable secureboot so that the 20.04.5 ISO can boot (press ESC when the VM is starting to access the boot menu): $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 20.04.5 ISO should boot. Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable: $ sudo mokutil --set-verbosity true $ sudo mokutil --set-sbat-policy delete $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted: $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log $ grep -I sbat.c focal-boot.log sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003 sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable. sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 20.04.5: $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled: $ mokutil --sb-state SecureBoot enabled [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media.
2023-04-26 20:46:46 Nick Rosbrook description [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing: $ mkdir test-lp2015664 $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages: $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs: $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script: $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level: $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation: $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu): $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable: $ sudo mokutil --set-verbosity true $ sudo mokutil --set-sbat-policy delete $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted: $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log $ grep -I sbat.c jammy-boot.log sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003 sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable. sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1: $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled: $ mokutil --sb-state SecureBoot enabled Test for Focal: NOTE: This test is the same as Jammy, except that we use the 20.04.5 ISO instead of the 20.04.5 ISO. * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level: $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 20.04.5 ISO, and observe the secureboot violation: $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso * Disable secureboot so that the 20.04.5 ISO can boot (press ESC when the VM is starting to access the boot menu): $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 20.04.5 ISO should boot. Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable: $ sudo mokutil --set-verbosity true $ sudo mokutil --set-sbat-policy delete $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted: $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log $ grep -I sbat.c focal-boot.log sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003 sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable. sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 20.04.5: $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled: $ mokutil --sb-state SecureBoot enabled [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media. [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing:  $ mkdir test-lp2015664  $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages:  $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs:  $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script:  $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm  $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log  $ grep -I sbat.c jammy-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled Test for Focal: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Disable secureboot and boot the 20.04.5 ISO (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log  $ grep -I sbat.c focal-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media.
2023-04-26 20:54:21 Nick Rosbrook description [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing:  $ mkdir test-lp2015664  $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages:  $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs:  $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script:  $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm  $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log  $ grep -I sbat.c jammy-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled Test for Focal: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Disable secureboot and boot the 20.04.5 ISO (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log  $ grep -I sbat.c focal-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media. [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing:  $ mkdir test-lp2015664  $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages:  $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs:  $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script:  $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm  $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log  $ grep -I sbat.c jammy-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled Test for Focal: NOTE: I have not actually been able to reproduce a secureboot violation when booting focal media, so this test simply verifies that mokutil in focal can use the --set-sbat-policy option successfully. * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Disable secureboot and boot the 20.04.5 ISO (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log  $ grep -I sbat.c focal-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media.
2023-04-28 14:30:37 Rod Smith bug added subscriber Rod Smith
2023-05-01 11:52:08 Julian Andres Klode mokutil (Ubuntu Focal): status New In Progress
2023-05-01 11:52:11 Julian Andres Klode mokutil (Ubuntu Jammy): status New In Progress
2023-05-01 11:52:22 Julian Andres Klode bug task deleted mokutil (Ubuntu)
2023-05-13 00:20:03 Steve Langasek mokutil (Ubuntu Jammy): status In Progress Fix Committed
2023-05-13 00:20:05 Steve Langasek bug added subscriber Ubuntu Stable Release Updates Team
2023-05-13 00:20:13 Steve Langasek bug added subscriber SRU Verification
2023-05-13 00:20:16 Steve Langasek tags fr-4055 fr-4055 verification-needed verification-needed-jammy
2023-05-19 20:12:23 Nick Rosbrook tags fr-4055 verification-needed verification-needed-jammy fr-4055 verification-done-jammy verification-needed
2023-05-20 00:19:57 Steve Langasek mokutil (Ubuntu Focal): status In Progress Fix Committed
2023-05-20 00:20:01 Steve Langasek tags fr-4055 verification-done-jammy verification-needed fr-4055 verification-done-jammy verification-needed verification-needed-focal
2023-05-23 17:27:20 Nick Rosbrook bug added subscriber Nick Rosbrook
2023-05-24 11:15:00 Launchpad Janitor mokutil (Ubuntu Jammy): status Fix Committed Fix Released
2023-05-24 11:15:05 Robie Basak removed subscriber Ubuntu Stable Release Updates Team
2023-05-24 14:04:27 Nick Rosbrook tags fr-4055 verification-done-jammy verification-needed verification-needed-focal fr-4055 verification-done verification-done-focal verification-done-jammy
2023-05-31 19:45:25 Launchpad Janitor mokutil (Ubuntu Focal): status Fix Committed Fix Released
2023-06-01 14:52:06 Steve Langasek tags fr-4055 verification-done verification-done-focal verification-done-jammy foundations-todo fr-4055 verification-done verification-done-focal verification-done-jammy
2023-06-01 15:04:36 Steve Langasek mokutil (Ubuntu Bionic): status New Triaged
2023-06-01 15:04:40 Steve Langasek mokutil (Ubuntu Bionic): importance Undecided High
2023-06-07 18:33:31 Nick Rosbrook description [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing:  $ mkdir test-lp2015664  $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages:  $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs:  $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script:  $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm  $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log  $ grep -I sbat.c jammy-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled Test for Focal: NOTE: I have not actually been able to reproduce a secureboot violation when booting focal media, so this test simply verifies that mokutil in focal can use the --set-sbat-policy option successfully. * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Disable secureboot and boot the 20.04.5 ISO (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log  $ grep -I sbat.c focal-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media. [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing:  $ mkdir test-lp2015664  $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages:  $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs:  $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script:  $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm  $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log  $ grep -I sbat.c jammy-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled Test for Focal: NOTE: I have not actually been able to reproduce a secureboot violation when booting focal media, so this test simply verifies that mokutil in focal can use the --set-sbat-policy option successfully. * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Disable secureboot and boot the 20.04.5 ISO (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log  $ grep -I sbat.c focal-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded Test for Bionic (same as Jammy but with 18.04.6 ISO): * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 18.04.6 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso * Disable secureboot so that the 18.04.6 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 18.04.6 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:bionic-boot.log  $ grep -I sbat.c bionic-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 18.04.6:  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media.
2023-06-07 18:34:30 Nick Rosbrook description [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing:  $ mkdir test-lp2015664  $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages:  $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs:  $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script:  $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm  $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log  $ grep -I sbat.c jammy-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled Test for Focal: NOTE: I have not actually been able to reproduce a secureboot violation when booting focal media, so this test simply verifies that mokutil in focal can use the --set-sbat-policy option successfully. * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Disable secureboot and boot the 20.04.5 ISO (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log  $ grep -I sbat.c focal-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded Test for Bionic (same as Jammy but with 18.04.6 ISO): * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 18.04.6 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso * Disable secureboot so that the 18.04.6 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 18.04.6 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:bionic-boot.log  $ grep -I sbat.c bionic-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 18.04.6:  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media. [Impact] After installing the most recent point releases of Ubuntu (Ubuntu 20.04.6, 22.04.2, or 23.04 beta), if the user has SecureBoot enabled (which is definitely recommended on UEFI systems) they will subsequently be unable to boot older OS install media which has not bumped its SBAT level since December 2022. While this is the correct default security policy as explained at https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996, users also need to be able to have control over their SBAT level so that they have the choice to downgrade the security level and boot other install media (up to and including older ESM-supported Ubuntu releases for which no updated media will be issued). In order to clear the SBAT level recorded in firmware, we need an updated version of mokutil corresponding to the shim which has been backported in these releases. [Test Plan] Preparation: * Create a directory for testing:  $ mkdir test-lp2015664  $ cd test-lp2015664 * Install ovmf and qemu-system-x86 packages:  $ sudo apt install ovmf qemu-system-x86 -y * Download 22.04.2, 22.04.1, and 20.04.5 ISOs:  $ wget https://releases.ubuntu.com/jammy/ubuntu-22.04.2-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/22.04.1/ubuntu-22.04.1-desktop-amd64.iso  $ wget https://old-releases.ubuntu.com/releases/20.04.5/ubuntu-20.04.5-desktop-amd64.iso * Download the secureboot-vm script:  $ wget https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+attachment/5668662/+files/secureboot-vm  $ chmod +x secureboot-vm Test for Jammy: * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 22.04.1 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso * Disable secureboot so that the 22.04.1 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 22.04.1 ISO should boot. Select "Try Ubuntu", and install mokutil from jammy-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:jammy-boot.log  $ grep -I sbat.c jammy-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 22.04.1:  $ ./secureboot-vm -cdrom ubuntu-22.04.1-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled Test for Focal: NOTE: I have not actually been able to reproduce a secureboot violation when booting focal media, so this test simply verifies that mokutil in focal can use the --set-sbat-policy option successfully. * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Disable secureboot and boot the 20.04.5 ISO (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-20.04.5-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and install mokutil from focal-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:focal-boot.log  $ grep -I sbat.c focal-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded Test for Bionic (same as Jammy but with 18.04.6 ISO): * Boot 22.04.2 ISO to grub, and then poweroff the VM. This boots the latest shim, which revokes the grub,1 SBAT level:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso * Attempt to boot the 18.04.6 ISO, and observe the secureboot violation:  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso * Disable secureboot so that the 18.04.6 ISO can boot (press ESC when the VM is starting to access the boot menu):  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso -boot menu=on * After disabling secureboot, the 18.04.6 ISO should boot. Select "Try Ubuntu", and install mokutil from bionic-proposed. Then, inside the live environment, set the verbosity level and instruct shim to delete SBAT variable:  $ sudo mokutil --set-verbosity true  $ sudo mokutil --set-sbat-policy delete  $ poweroff * Boot 22.04.2 to grub again, which will delete the SBAT variable. Save the serial output to verify that the SBAT variable is deleted:  $ ./secureboot-vm -cdrom ubuntu-22.04.2-desktop-amd64.iso -serial file:bionic-boot.log  $ grep -I sbat.c bionic-boot.log  sbat.c:477:set_sbat_uefi_variable() SbatLevel variable is 25 bytes, attributes are 0x00000003  sbat.c:479:set_sbat_uefi_variable() Deleting SbatLevel variable.  sbat.c:512:set_sbat_uefi_variable() SbatLevel variable initialization succeeded * Finally, re-enable secureboot and then boot into 18.04.6:  $ ./secureboot-vm -cdrom ubuntu-18.04.6-desktop-amd64.iso -boot menu=on * Select "Try Ubuntu", and once inside the live environment, double check that secureboot is enabled:  $ mokutil --sb-state  SecureBoot enabled [Where problems could occur] Since this SRU would backport an entire version to Jammy and Kinetic, I cannot practically examine all of the code changes to assess which features of mokutil have changed. The package only ships the mokutil binary and some documentation, so the regression potential is limited to the tool itself, which has a very limited and specific purpose. [Other Info] The entire purpose of the mokutil tool is to manage firmware entries that are read by MokManager, which is part of shim. Hence, it makes sense to keep shim and mokutil in lockstep, and this SRU could be considered HWE enablement. In particular, users need to be able to clear the SBAT level if needed to boot older install media.
2023-06-07 18:36:40 Nick Rosbrook merge proposal linked https://code.launchpad.net/~enr0n/ubuntu/+source/mokutil/+git/mokutil/+merge/444298
2023-06-07 20:35:49 Steve Langasek mokutil (Ubuntu Bionic): status Triaged In Progress
2023-06-07 20:35:51 Steve Langasek mokutil (Ubuntu Bionic): assignee Steve Langasek (vorlon)
2023-06-12 14:27:56 Łukasz Zemczak mokutil (Ubuntu Bionic): status In Progress Fix Committed
2023-06-12 14:27:57 Łukasz Zemczak bug added subscriber Ubuntu Stable Release Updates Team
2023-06-12 14:28:07 Łukasz Zemczak tags foundations-todo fr-4055 verification-done verification-done-focal verification-done-jammy foundations-todo fr-4055 verification-done-focal verification-done-jammy verification-needed verification-needed-bionic
2023-06-12 16:35:28 Nick Rosbrook tags foundations-todo fr-4055 verification-done-focal verification-done-jammy verification-needed verification-needed-bionic foundations-todo fr-4055 verification-done verification-done-bionic verification-done-focal verification-done-jammy
2023-06-20 07:46:19 Launchpad Janitor mokutil (Ubuntu Bionic): status Fix Committed Fix Released
2023-10-23 15:09:00 Benjamin Drung tags foundations-todo fr-4055 verification-done verification-done-bionic verification-done-focal verification-done-jammy fr-4055 verification-done verification-done-bionic verification-done-focal verification-done-jammy