[Bug 2015664] Re: backport needed to enable users to reset SBAT level
Nick Rosbrook
2015664 at bugs.launchpad.net
Wed Apr 26 20:46:46 UTC 2023
** Description changed:
[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
+ $ mkdir test-lp2015664
+ $ cd test-lp2015664
* Install ovmf and qemu-system-x86 packages:
- $ sudo apt install ovmf qemu-system-x86 -y
+ $ 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
+ $ 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
+ $ 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
+ $ ./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
+ $ ./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
+ $ ./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
+ $ 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
+ $ ./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
+ $ ./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
+ $ 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
- * 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
- * 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
+ * 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
+ $ ./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.
** Description changed:
[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.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mokutil in Ubuntu.
Matching subscriptions: mokutil-bugs
https://bugs.launchpad.net/bugs/2015664
Title:
backport needed to enable users to reset SBAT level
Status in mokutil package in Ubuntu:
New
Status in mokutil source package in Focal:
New
Status in mokutil source package in Jammy:
New
Bug 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/2015664/+subscriptions
More information about the foundations-bugs
mailing list