[Bug 2015664] Re: backport needed to enable users to reset SBAT level

Mon May 1 11:56:12 UTC 2023

Uploads sponsored w/ minor adjustment to reduce debian/compat to 12 in
focal as well, matching the depends, as lintian complained about level
13 not being ready then yet. Build output is binary identical.

$ md5sum {~/Downloads,..}/mokutil_0.6.0-2~20.04.1_amd64.deb
f0db822020bf68509153e4e900037362  /home/jak/Downloads/mokutil_0.6.0-2~20.04.1_amd64.deb
f0db822020bf68509153e4e900037362  ../mokutil_0.6.0-2~20.04.1_amd64.deb

** Changed in: mokutil (Ubuntu Focal)
       Status: New => In Progress

** Changed in: mokutil (Ubuntu Jammy)
       Status: New => In Progress

** No longer affects: mokutil (Ubuntu)

-- 
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 source package in Focal:
  In Progress
Status in mokutil source package in Jammy:
  In Progress

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/focal/+source/mokutil/+bug/2015664/+subscriptions