rebuild debian-installer against current boot stack (SecureBoot security updates / revocations)

Hello Steve, or anyone else affected,

Accepted debian-installer into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu614.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

confirmed from the build log that the correct package versions were picked up.

https://cdimage.ubuntu.com/focal/daily-live/20230302.1/ should have been built with the updated debian-installer.

I don't think we actually did any testing of the debian-installer packages. I think we need a rebuild of ubiquity for everything to work as expected? Since we're now working on .6, I'll release this to -updates and all the verification of this working with the new keys will be done as part of .6.

This bug was fixed in the package debian-installer - 20101020ubuntu614.5

---------------
debian-installer (20101020ubuntu614.5) focal; urgency=medium

  * No-change rebuild against shim-signed 1.40.9+15.7-0ubuntu1 and
    grub2-signed 1.187.3~20.04.1+2.06-2ubuntu14.1. LP: #2009078.

 -- Steve Langasek <email address hidden> Thu, 02 Mar 2023 13:27:30 -0800

Ubiquity is not relevant to this. The boot bits are pulled by debian-cd from the archive mirror at image build time.

Configured a new VM under virt-manager, using the option 'Customize configuration before install' and selecting 'OVMF_CODE_4M.ms.fd' as the firmware. Booted Ubuntu 22.04.2 install media. Verified firmware settings were as expected with 'mokutil --db' and 'mokutil --sb-state'. Verified that SBAT had been applied by confirming /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23 was present.

Enabled focal-proposed in sources and ran 'apt install secureboot-db=1.6~20.04.1'. Confirmed with 'mokutil --dbx' that the Canonical 2012 signing key was present.

Shut down the VM, reconfigured to boot 20.04.5. 20.04.5 booted to grub without a security error. So the test case is incomplete, working on revising.

With the revised test case, confirm that 20.04.5 media fails to boot with (under OVMF) 'Access Denied'.

Downloading https://cdimage.ubuntu.com/focal/daily-live/20230314.1/focal-desktop-amd64.iso, the boot also fails. This time it fails with an error from shim when trying to chain to grub: 'Verification failed: (0x1A) Security Violation'.

This is because archive publication of the signed binaries from grub has changed, and debian-installer was not updated to know this so was still picking up the last grub*.efi published under the old method.

Working on fixing debian-installer now.

Hello Steve, or anyone else affected,

Accepted debian-installer into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu614.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

20101020ubuntu614.6 built and 20230314.2 Ubuntu Desktop daily image is being built to include it.

Correction: 20230314.3

https://cdimage.ubuntu.com/focal/daily-live/20230314.3/focal-desktop-amd64.iso passes the test case in the same VM.

This bug was fixed in the package debian-installer - 20101020ubuntu614.6

---------------
debian-installer (20101020ubuntu614.6) focal; urgency=medium

  * Fix debian-installer to pull gcdx64.efi.signed from the
    grub-efi-amd64-signed binary package (already installed as a transitive
    build-dependency) instead of from the archive mirror, where it is no
    longer published. LP: #2009078.

 -- Steve Langasek <email address hidden> Tue, 14 Mar 2023 12:50:04 -0700

The verification of the Stable Release Update for debian-installer has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

"Try to boot Ubuntu 20.04.5 media. Confirm that the boot is blocked with a security error." Oddly, when I got to this step, the 20.04.5 boot was indeed blocked, but *not* with a security violation error. My virt-manager VM with Secure Boot simply silently failed to boot the ISO. 20.04.6 boots on the same VM. Anyway, it looks like things are functioning as intended, but I thought that was worth noting.

On Wed, Mar 15, 2023 at 02:51:36AM -0000, Aaron Rainbolt wrote:

> Oddly, when I got to this step, the 20.04.5 boot was indeed blocked, but
> *not* with a security violation error. My virt- manager VM with Secure
> Boot simply silently failed to boot the ISO.

ovmf doesn't print a message when this happens, it just moves on to the next
boot option (probably the shell). You can forcibly get a message by running
fs0:\efi\boot\bootx64.efi from the shell.

On real hardware with production firmware, there is no shell so the boot
stops and you see the security violation message.