Unable to boot in UEFI+secure boot mode

[Leó Kolbeinsson]

The problem:

Trying to install the QA daily build for Kubuntu Groovy 20200824 - when booting from the USB boot media I receive the following error:

Error

Verification failed:
(0x1A) security violation

Followed by an OK box - which when selected offers to import the SHIM key

This error occurred on 2 machines running in UEFI+secure boot mode:

1: Dell [Inspiron] 3521, (i3-3217U, 4GB, Intel HD Graphics 4000, Intel HM76 chipset 10/100 Mbps ethernet controller integrated on system board, WiFi 802.11 b/g/N, Bluetooth 4.0, 500 GB hd)

2: Acer [Aspire] E3-111-P60S (Pent.N3530, 4GB, Intel HD Graphics, Realtek RTL8111/81681/8411 GB Ethernet, Qualcomm Atheros AR9462 Wireless, Bluetooth Atheros A315-53, 500 GB hd)

Disabling secure boot the machines then boot normally in UEFI mode

Will test further some of the other flavors..

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1892754

[Leó Kolbeinsson (leok)]

Just performed a quick test on the Dell [Inspiron] 3521, box this time running in UEFI without secure boot and the system booted up normally and the install completed without error.

[Leó Kolbeinsson (leok)]

Further testing on the two boxes that failed:

1. Dell [Inspiron] 3521 - failed when attempting to boot UFEI + secure boot from media and install Lubuntu Groovy 20200824

2. Acer [Aspire] E3-111-P60S - booted UEFI+secure boot and installed Lubuntu Groovy 20200824 with no errors.

[Leó Kolbeinsson (leok)]

Further test:

1.Dell [ Optiplex] MT 7040 ( i7-6700,16 GB, Intel HD Graphics 530,Intel i219-LM GB Ethernet, 1 TB hd)boot UFEI + secure boot from media and install Lubuntu Groovy 20200825 booted successfully

2. Dell [Inspiron] 3521 - failed when attempting to boot UFEI + secure boot from media and install Lubuntu Groovy 20200825

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[sudodus (nio-wiklund)]

This bug affects my Dell Precision M4800 too.

A current daily Lubuntu Groovy iso file cloned to a USB drive works in BIOS mode and UEFI mode without secure boot, but with secure boot I get this message:

'Error: security violation'

and the boot process cannot continue.

I double-checked and a Focal iso file works in secure boot in this computer.

[sudodus (nio-wiklund)]

Need I say that the old failure mode is still there in a Lenovo V130:

https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/comments/60

[Chris Guiver (guiverc)]

yeah me too it turned out
(I finally discovered I can turn secure boot on this thing)

sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
"ERROR - Verfication failed: (0x1A) Security Violation"

[sudodus (nio-wiklund)]

Additional test results:

- As before, the Lenovo V130 can boot when the current daily Lubuntu Groovy iso file is used to create a persistent live drive with mkusb (with the setting 'upefi', using 'usb-pack-efi'). This indicates that there is a security problem with grub.

- The Dell Precision M4800 does *not* boot when the current daily Lubuntu Groovy iso file is used to create a persistent live drive with mkusb (with the setting 'upefi', using 'usb-pack-efi'). The internal Ubuntu 20.04.1 LTS system is up to date, and I think that the new stricter checks to fix the boothole security bug is active in this computer.

Extra comments:

- The internal system in the Lenovo V130 has not been upgraded recently because that computer has not been used except for this test to boot a live system).

- I must probably upgrade the 'usb-pack-efi' of mkusb with a grub version, that passes the new stricter checks to fix the boothole security bug.

[sudodus (nio-wiklund)]

I tried again in the Lenovo V130, and this second time the internal UEFI system is upgraded so that it no longer allows booting (not even when the current daily Lubuntu Groovy iso file is used to create a persistent live drive with mkusb (with the setting 'upefi', using 'usb-pack-efi'). So the bugfix against the boothole seems to have entered this computer during the first session.

[sudodus (nio-wiklund)]

This bug affects the current Ubuntu Desktop Groovy iso file too (not only Lubuntu).

[Chris Guiver (guiverc)]

Last night I wrote a recent Ubuntu daily image to thumb-drive and tried to boot it on

sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)
which now has secure boot on and it failed with

"ERROR
Verification failed: (0x1A) Security Violation"

Today I've upgrade ISO and now it's 2020-08-28 and thus reported on iso.qa.ubuntu.com.

It was written two ways to media
- `dus` or mkusb
- gnome-disks restore image

Both times it fails on the sony vaio crapbook with listed error.
The thumb-drive media booted both times (`dus` or gnome-disks) on other non-secure-UEFI boxes

Disable secure-boot on sony ultracrap and Ubuntu groovy will boot. The ISO won't boot with secure-boot enabled.

[Steve Langasek (vorlon)]

I am unable to reproduce this issue here using an unmodified, current groovy image of either Ubuntu (http://cdimage.ubuntu.com/ubuntu/daily-live/20200826/groovy-desktop-amd64.iso) or Kubuntu (http://cdimage.ubuntu.com/kubuntu/daily-live/20200831/groovy-desktop-amd64.iso) in a KVM instance configured with the Microsoft SecureBoot keys.

Is this problem still reproducible for you with the current daily images listed above?

What are the contents of your secureboot firmware variables, as reported by mokutil --db and mokutil --dbx?

> Followed by an OK box - which when selected offers to import the SHIM key

What key, exactly, are you being offered to import? Can you please attach a screenshot?

[Chris Guiver (guiverc)]

The Ubuntu daily image I used in testing (http://cdimage.ubuntu.com/ubuntu/daily-live/20200826/groovy-desktop-arm64.iso.zsync) and matches comment #13 still fails to boot with secure boot enabled

sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

- mokutil --db
https://paste.ubuntu.com/p/gdsMxpwztZ/

- mokutil --dbx
https://paste.ubuntu.com/p/3PtC2zzKfP/ (dbx)

(created on same sony device booting the ISO with secure boot disabled)

The subsequent screens I see on hitting OK are

- continue boot, enroll key from disk, enroll hash from disk
https://photos.app.goo.gl/Ve4PMQexDSfGcdWy5

- select key (ESP or PciRoot(0)/Pci...)
https://photos.app.goo.gl/sKbVRTvbKQqCcbpz8

I have done nothing at this prompt; I just exited.

I don't own a box new enough to have secure boot so I've never learnt it (this sony isn't mine but can use it for testing for now, but have before now always had secure boot disabled).

Maybe for older folks like me we need a wiki walk-through page for this?

[Steve Langasek (vorlon)]

Ok, a key point here is that your dbx includes Microsoft's recent revocations of older grub versions; and an examination of the daily image shows that it's currently using an old grub signed with the old key instead of the current grub:

$ sudo kpartx -a ~/devel/iso/groovy-desktop-amd64.iso
$ sudo mount /dev/mapper/loop8p2 /mnt
$ sbattach -d /tmp/grub.sig /mnt/efi/boot/grubx64.efi
$ openssl pkcs7 -noout -inform DER -in /tmp/grub.sig -print_certs
subject=C = GB, ST = Isle of Man, O = Canonical Ltd., OU = Secure Boot, CN = Canonical Ltd. Secure Boot Signing

issuer=C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., CN = Canonical Ltd. Master Certificate Authority

$ sudo umount /mnt
$ sudo kpartx -d ~/devel/iso/groovy-desktop-amd64.iso
$

This is not a bug in grub but in the construction of the daily images, which apparently do not automatically track the current grub.

[Steve Langasek (vorlon)]

cd-boot-images-amd64 v 5 has been uploaded, to pull in the new grub. This will be fixed in daily images as soon as that propagates.

[Chris Guiver (guiverc)]

Thanks Steve Langasek/@vorlon

[Leó Kolbeinsson (leok)]

Thanks @vorlon .. will test the new images when available.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cd-boot-images-amd64 - 5

---------------
cd-boot-images-amd64 (5) groovy; urgency=medium

  * No-change rebuild against current grub, to pick up a version that
    is signed with the current, non-revoked key. LP: #1892754.

 -- Steve Langasek <email address hidden> Mon, 31 Aug 2020 23:06:39 -0700

[Leó Kolbeinsson (leok)]

Tested Lubuntu Groovy on 3 machines - ISO downloaded from QA testing tracker 20200901

http://iso.qa.ubuntu.com/qatracker/milestones/413/builds/219871/downloads -

All 3 booted successfully in UEFI+secure mode. Results posted on the QA Testing tracker site.

[sudodus (nio-wiklund)]

Thanks, this bug is squashed :-)

I can confirm that a USB drive cloned from the current daily Lubuntu iso file boots in UEFI mode with secure boot in my Dell Precision M4800.

(This computer can also boot in UEFI mode without secure boot and in BIOS mode with the current daily Lubuntu iso file.)

The old problem that a Lenovo V130 in UEFI mode with secure boot fails is still there and independent of the bug reported here.

[Steve Langasek (vorlon)]

On Wed, Sep 02, 2020 at 11:15:28AM -0000, sudodus wrote:
> The old problem that a Lenovo V130 in UEFI mode with secure boot fails
> is still there and independent of the bug reported here.

Do you have a bug reference for this, please? And I would want the same
kind of debugging information from this system, to see what is in the db and
dbx variables in firmware.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
<email address hidden> <email address hidden>

[sudodus (nio-wiklund)]

The problem with the Lenovo V130 was reported at this bug report/comment:

https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/comments/31

[sudodus (nio-wiklund)]

@ Steve Langasek (vorlon),

Previously I have not touched the UEFI/BIOS system of the *Lenovo V130* that I have access to, but now, that you ask about it, I had better do it in order to help identify what goes wrong, when trying to boot USB drives cloned from Groovy ISO files.

When testing Groovy iso files, the fix against the boothole bug was entered into this computer, so that USB drives that used to boot would no longer boot.

I turned off secure boot, and then it was possible again to boot for example Ubuntu 20.04.1 LTS (cloned to a USB drive). This matches the observation, that Groovy iso files worked until you modified the boot system (when you removed syslinux boot in BIOS mode, but obviously also modified the boot system in UEFI mode).

But USB drives cloned from the current Ubuntu Groovy as well as Lubuntu Groovy do not boot.

[sudodus (nio-wiklund)]

... continuing:

This is when using the boot option in the temporary boot menu (F12)

"Linpus Lite (<name of the USB drive>)"

in the picture attached to the previous comment. This is the only available USB boot option in UEFI mode.

Then I turned off UEFI mode and set teh computer to boot in 'legacy mode'. Now there were more boot options in the temporary boot menu (F12). These options are shown in the picture attached to the previous comment. The option

"USB Hdd: <name of the USB drive>"

*works* also with USB drives cloned from the current Ubuntu Groovy as well as Lubuntu Groovy.

So the problem in this case is not due to secure boot, but the "Linpus Lite" boot option does not work with the current Groovy iso files. It works with older iso files including Ubuntu 20.04.1 LTS and Groovy iso files from before you modified the boot system (when you removed syslinux boot in BIOS mode, but obviously also modified the boot system in UEFI mode).

[Steve Langasek (vorlon)]

Please either file a separate bug report for the Lenovo V130 issue, or follow up on LP: #1886148, rather than commenting on a closed bug.

> This is when using the boot option in the temporary boot menu (F12)

> "Linpus Lite (<name of the USB drive>)"

This suggests to me that this is an EFI boot entry that was manually configured at some point in the past, rather than a firmware-provided boot target. And the manual configuration may not be correct for booting Ubuntu ISOs (but perhaps it works with older images by chance). I would want to see the output of `efibootmgr -v` from this system when Ubuntu is booted under UEFI (but again, not on this closed bug report, please).

[sudodus (nio-wiklund)]

@ Steve Langasek (vorlon),

According to your request I continue the dialogue about the Lenovo V130 issue at

https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/