DBX Update can't be installed due to binaries on ESP for recovery partition

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

Hello Harry,

Looking at the commit "Always check the BDP partitions when getting all the possible ESPs", https://github.com/fwupd/fwupd/commit/ce63e44395f28746adf4ff274442925d8e621585 it seems that a very specific setup with an incorrect partition type for the ESP is needed to reproduce what is fixed by this change.

Could you, please, indicate what is needed to reproduce your problem including your input, the console output, and the expected result.

Please, run 'apport-collect 1990179' to provide system information.

Best regards

Heinrich

apport information

apport information

apport information

apport information

apport information

To reproduce this problem, one must be on a Dell Precision 7760 Laptop running Ubuntu 20.04 and run

sudo fwupdmgr update

As long as Dell keeps the dbx database update in the lvfs stream, which is currently
the case, the problem will occur.

> # This is the distribution channel descriptor for the OEM CDs
> # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
> canonical-oem-somerville-focal-amd64-20200502-85

I have a sneaking suspicion that based on the way this system is installed the ESP identifies as a BDP not an ESP.

Can you please run

# sudo fwupdtool esp-list --verbose

If my suspicion is correct, you might be able to avoid this problem if you reclassify the BDP as an ESP type partition. It *might* also be worth pushing out such an update to reclassify for any factory shipped machines if that helps.

This system is purchased from Dell with Ubuntu 20.04 already installed and no windows partition,
so however /boot is laid out is how Dell distributes such systems. I attached the eps-list output.

Did you use --verbose? I want to confirm the partition types identified.

I had to cut and paste the --verbose output from the screen for

sudo fwupdtool esp-list --verbose

Here it is:

23:34:52:0827 FuDebug Verbose debugging enabled (on console 1)
23:34:52:0842 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b, internal: 1, fs: vfat
23:34:52:0847 FuCommon device /org/freedesktop/UDisks2/block_devices/sdb1, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 0, fs: ext4
23:34:52:0849 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
23:34:52:0850 FuCommon device /org/freedesktop/UDisks2/block_devices/sda1, type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7, internal: 0, fs: ntfs
23:34:52:0851 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: e3c9e316-0b5c-4db8-817d-f92df00215ae, internal: 1, fs: vfat

Together with the esp-list.txt I already uploaded here, that is all fwupdtool provided...
/boot/efi is a vfat partition...

I believe the /boot partition has always been vfat on every Dell computer I've had...

/dev/nvme0n1p1 763904 56064 707840 8% /boot/efi

The important part isn't the filesystem type but the partition identification type.

> c12a7328-f81f-11d2-ba4b-00a0c93ec93b

This corresponds to an ESP type of partition.
https://fwupd.github.io/libfwupdplugin/const.VOLUME_KIND_ESP.html

This means that the solution you linked: https://github.com/fwupd/fwupd/commit/ce63e44395f28746adf4ff274442925d8e621585

Will have no impact on your machine. If you're having a failure, we should debug is separately.

So to debug, how about sharing the following log output:

sudo fwupdtool update --verbose

That will get the engine output combined with tool output (which is the same as the daemon output when run in client/server architecture).

Regarding the request to do "sudo fwupdmgr update --verbose":

I have included that output below, but it may not show you much because before I really
knew what was happening when this error first occurred around a week ago now, google seraches
revealed that errors of this type might be gotten around by temprorarily removing the
offending file and then trying the update. Before doing that I would always get the same error
every time I did the fwupdmgr update. So, I temporarily removed /boot/efi/efi.factory/boot/bootx64.efi
and then the update succeeded, at least according to the fwupd code reports. So then
I moved bootx64.efi back where it belonged and the fwupd code has worked fine ever since.
Hence the log for the above fwupdmgr command probably won't help. BUT -- I did keep the
original error I was getting. That error follows:

╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 77 to 217? ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ This updates the dbx to the latest release from Microsoft which adds ║
║ insecure versions of grub and shim to the list of forbidden signatures due ║
║ to multiple discovered security updates. ║
║ ║
║ UEFI dbx and all connected devices may not be usable while updating. ║
╚══════════════════════════════════════════════════════════════════════════════╝

Perform operation? [Y|n]: Y
Downloading… [***************************************]
Downloading… [***************************************]
Decompressing… [***************************************]
Decompressing… [***************************************]
Authenticating… [***************************************]
Authenticating… [***************************************]
Restarting device… [***************************************]
Writing… [***************************************]
Decompressing… [***************************************]
Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/efi.factory/boot/bootx64.efi Authenticode checksum [2ea4cb6a1f1eb1d3dce82d54fde26ded243ba3e18de7c6d211902a594fe56788] is present in dbx

The output from the current runs of fwupdmgr update --verbose that was requested is:
(fwupdmgr:58481): GLib-DEBUG: 20:20:30.629: setenv()/putenv() are not thread-safe and should not be used after threads are created
(fwupdmgr:58481): GLib-GIO-DEBUG: 20:20:30.630: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
(fwupdmgr:58481): dconf-DEBUG: 20:20:30.630: watch_fast: "/system/proxy/" (establishing: 0, active: 0)
(fwupdmgr:58481): dconf-DEBUG: 20:20:30.630: watch_fast: "/system/proxy/http/" (establishing: 0, active: 0)
(fwupdmgr:58481): dconf-DEBUG: 20:20:30.630: watch_fast: "/system/proxy/https/" (establishing: 0, active: 0)
(fwupdmgr:58481): dconf-DEBUG: 20:20:30.630: watch_fast: "/system/proxy/ftp/" (es...

I didn't request fwupdmgr update --verbose, I requested fwupdtool update --verbose. There was a reason I requested that difference.

Anyway though; the problem is very clear now from your output from fwupdgmr as well.

Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/efi.factory/boot/bootx64.efi Authenticode checksum [2ea4cb6a1f1eb1d3dce82d54fde26ded243ba3e18de7c6d211902a594fe56788] is present in dbx

What is going on is that the ESP contains another bootloader that is used for the recovery partition, which if secureboot DBX update was pushed down would no longer be able to execute. This other bootloader needs to be updated before the DBX update will be accepted.

I have the same problem. Who is supposed to update /boot/efi/efi.factory/boot/bootx64.efi, does Dell have to release a new firmware update?

I have asked Dell support about this, they told me Ubuntu support was limited and I should apply the updates under Windows.

Did Dells support explain how to updated this under Windows? I do have dual boot but got no such update yet?

Can you please locate the path to this file? If it lives in the ESP partition or it in reality lives in the Recovery Partition which in your case should be nvme0n1p1 and nvme0n1p2 respectively.

/efi.factory/boot/bootx64.efi

fwupd should only scan the ESP partition for potential efi executables.

in my case the /efi.factory/boot/bootx64.efi is located in /boot/efi/efi.factory/boot/. /boot/efi/ is on the nvme0n1p1.

I checked on Dell precision 7750, but I didn't see efi.factory. I try to check firmware update, but there is no firmware update available, may I have steps to reproduce the issue?

ubuntu@precision-7750-c3-202004-27810:~$ sudo fwupdtool esp-list --verbose
07:40:46:0339 FuDebug Verbose debugging enabled (on console 1)
07:40:46:0354 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme3n1p2, type: e3c9e316-0b5c-4db8-817d-f92df00215ae, internal: 1, fs: vfat
07:40:46:0357 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
07:40:46:0360 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme3n1p1, type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b, internal: 1, fs: vfat
07:40:46:0361 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b, internal: 1, fs: vfat
07:40:46:0363 FuCommon device /org/freedesktop/UDisks2/block_devices/sda1, type: 0x83, internal: 0, fs: ext4
07:40:46:0364 FuCommon device /org/freedesktop/UDisks2/block_devices/mmcblk0p1, type: 0x83, internal: 0, fs: vfat
07:40:46:0365 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme3n1p3, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
Choose a volume:
0. Cancel
1. /org/freedesktop/UDisks2/block_devices/nvme3n1p1
2. /org/freedesktop/UDisks2/block_devices/nvme0n1p1
2
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/efi/EFI/ubuntu/shimx64.efi
/boot/efi/EFI/ubuntu/mmx64.efi
/boot/efi/EFI/ubuntu/BOOTX64.CSV
/boot/efi/EFI/ubuntu/grub.cfg
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/fbx64.efi
/boot/efi/EFI/BOOT/mmx64.efi

It's harmless to remove efi.factory directory from the ESP, ideally it should live at the root of recovery partition.

So you suggest that I could delete, well better move, /boot/efi/efi.factory/?

Btw. here the output of "sudo fwupdtool esp-list --verbose" on my XPS13 (9310) dual-boot:

08:35:07:0695 FuDebug Verbose debugging enabled (on console 1)
08:35:07:0746 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b, internal: 1, fs: vfat
08:35:07:0750 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p6, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: crypto_LUKS
08:35:07:0759 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p5, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
08:35:07:0765 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p4, type: de94bba4-06d1-4d40-a16a-bfd50179d6ac, internal: 1, fs: ntfs
08:35:07:0771 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: e3c9e316-0b5c-4db8-817d-f92df00215ae, internal: 1, fs:
08:35:07:0774 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7, internal: 1, fs: BitLocker
Selected volume: /org/freedesktop/UDisks2/block_devices/nvme0n1p1
/boot/efi/EFI/Boot/BOOTX64.EFI
/boot/efi/EFI/Boot/en-us/bootx64.efi.mui
/boot/efi/EFI/Boot/fbx64.efi
/boot/efi/EFI/Boot/mmx64.efi
/boot/efi/EFI/Microsoft/Boot/BCD
/boot/efi/EFI/Microsoft/Boot/en-us/bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/en-us/memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/en-us/bootmgfw.efi.mui
/boot/efi/EFI/Microsoft/Boot/Fonts/chs_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/cht_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/jpn_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/kor_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/malgunn_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/malgun_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/meiryon_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/meiryo_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/msjhn_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/msjh_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/msyhn_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/msyh_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/segmono_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/segoen_slboot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/segoe_slboot.ttf
/boot/efi/EFI/Microsoft/Boot/Fonts/wgl4_boot.ttf
/boot/efi/EFI/Microsoft/Boot/Resources/bootres.dll
/boot/efi/EFI/Microsoft/Boot/Resources/de-DE/bootres.dll.mui
/boot/efi/EFI/Microsoft/Boot/BCD.LOG
/boot/efi/EFI/Microsoft/Boot/BCD.LOG1
/boot/efi/EFI/Microsoft/Boot/BCD.LOG2
/boot/efi/EFI/Microsoft/Boot/bg-BG/bootmgfw.efi.mui
/boot/efi/EFI/Microsoft/Boot/bg-BG/bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/kd_0C_8086.dll
/boot/efi/EFI/Microsoft/Boot/cs-CZ/bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/cs-CZ/memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/cs-CZ/bootmgfw.efi.mui
/boot/efi/EFI/Microsoft/Boot/da-DK/bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/da-DK/memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/da-DK/bootmgfw.efi.mui
/boot/efi/EFI/Microsoft/Boot/de-DE/bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/de-DE/memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/d...

The efi application under efi.factory is unlikely a boot option in your case, to verify it you can check there's no use at all by $ efibootmgr -v

Given it is unused, and fwupd at present compares it with dbx so the quickest solution you can do is simply remove it from the ESP, yes would be better to move it to Ubuntu's RP.

No usage of efi.factory:

~$ efibootmgr -v
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0006,0001,0004,0000,0002,0003
Boot0000* UEFI KXG60ZNV1T02 NVMe KIOXIA 1024GB 515F71X1F8S3 1 PciRoot(0x0)/Pci(0x6,0x0)/Pci(0x0,0x0)/NVMe(0x1,8C-E3-8E-05-00-7C-61-73)/HD(1,GPT,b67bf31f-5998-4c1a-9f2f-ffddf1616697,0x800,0x197800)/File(\EFI\Boot\BootX64.efi)N.....YM....R,Y.
Boot0001* Windows Boot Manager HD(1,GPT,b67bf31f-5998-4c1a-9f2f-ffddf1616697,0x800,0x197800)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0002* USB NIC (IPV4) PciRoot(0x0)/Pci(0x7,0x0)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/USB(0,0)/USB(1,0)/MAC(381428b53988,0)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
Boot0003* USB NIC (IPV6) PciRoot(0x0)/Pci(0x7,0x0)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/USB(0,0)/USB(1,0)/MAC(381428b53988,0)/IPv6([::]:<->[::]:,0,0)N.....YM....R,Y.
Boot0004* Linux Firmware Updater HD(1,GPT,b67bf31f-5998-4c1a-9f2f-ffddf1616697,0x800,0x197800)/File(\EFI\ubuntu\shimx64.efi)\.f.w.u.p.d.x.6.4...e.f.i...
Boot0006* ubuntu HD(1,GPT,b67bf31f-5998-4c1a-9f2f-ffddf1616697,0x800,0x197800)/File(\EFI\ubuntu\shimx64.efi)

So I will go ahead and move it. What do you mean by Ubuntu's RP?

Thanks

I did notice that the grubx64.efi is present in /boot/efi/EFI/ubuntu & /boot/efi/efi.factory/boot:

chri@nbChri:~$ sudo ls -l /boot/efi/efi.factory/boot
insgesamt 2692
-rwx------ 1 root root 1334816 Sep 4 2020 bootx64.efi
-rwx------ 1 root root 1419136 Sep 4 2020 grubx64.efi
chri@nbChri:~$ sudo ls -l /boot/efi/EFI/ubuntu
insgesamt 3692
-rwx------ 1 root root 108 Aug 27 00:00 BOOTX64.CSV
drwx------ 2 root root 4096 Sep 15 08:56 fw
-rwx------ 1 root root 64872 Apr 12 2022 fwupdx64.efi
-rwx------ 1 root root 112 Aug 27 00:00 grub.cfg
-rwx------ 1 root root 1742728 Aug 27 00:00 grubx64.efi
-rwx------ 1 root root 47966 Jul 12 2021 loadefi.efi
-rwx------ 1 root root 856232 Aug 27 00:00 mmx64.efi
-rwx------ 1 root root 955656 Aug 27 00:00 shimx64.efi
-rwx------ 1 root root 87008 Jul 12 2021 UbuntuSecBoot.efi

> What do you mean by Ubuntu's RP?

It means the recovery partition where the efi.factory should move to.

Thanks, I can confirm that after moving the files the update worked for me

VERSION="22.04.1 LTS (Jammy Jellyfish)"
Dell 7750

DELL7750:~/Downloads> sudo fwupdmgr update
Devices with no available firmware updates:
 • SSD 970 EVO Plus 2TB
 • SSD 970 EVO Plus 2TB
 • Thunderbolt host controller
 • UEFI Device Firmware
 • UEFI Device Firmware
Devices with the latest available firmware version:
 • BC711 NVMe SK hynix 256GB
 • System Firmware
╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 77 to 217? ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ This updates the dbx to the latest release from Microsoft which adds ║
║ insecure versions of grub and shim to the list of forbidden signatures due ║
║ to multiple discovered security updates. ║
║ ║
║ Before installing the update, fwupd will check for any affected executables ║
║ in the ESP and will refuse to update if it finds any boot binaries signed ║
║ with any of the forbidden signatures.If the installation fails, you will ║
║ need to update shim and grub packages before the update can be deployed. ║
║ ║
║ Once you have installed this dbx update, any DVD or USB installer images ║
║ signed with the old signatures may not work correctly.You may have to ║
║ temporarily turn off secure boot when using recovery or installation media, ║
║ if new images have not been made available by your distribution. ║
║ ║
║ UEFI dbx and all connected devices may not be usable while updating. ║
╚══════════════════════════════════════════════════════════════════════════════╝

Perform operation? [Y|n]:
Downloading… [***************************************]
Decompressing… [***************************************]
Decompressing… [***************************************]
Authenticating… [***************************************]
Authenticating… [***************************************]
Restarting device… [***************************************]
Writing… [***************************************]
Decompressing… [***************************************]
Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/EFI/Boot/shimx64.efi Authenticode checksum [007f4c95125713b112093e21663e2d23e3c1ae9ce4b5de0d58a297332336a2d8] is present in dbx

DELL7750:~/Downloads> sudo fwupdtool esp-list --verbose
18:24:08:0819 FuDebug Verbose debugging enabled (on console 1)
18:24:08:0873 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme1n1p3, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
18:24:08:0877 FuCommon device /org/freedesktop/UDisks2/block_devices/nvme1n1p2, type: e3c9e316-0b5c-4db8-817d-f92df00215ae, internal: 1, fs: vfat
18:24:08:0881 FuCommon device /org/freedesktop/UDisks2/block_d...

No, in your case it looks like your shim would no longer boot after you installed the update.

Upload package to fix invalid efi.factory directory in ESP partition.
copy deb package to OS and run command "dpkg -i oem-config-esp_1_all.deb" to install package.

Is it safe to install the above package?

I'm having the same problem - unable to update "secure boot dbx configuration update"

See my thread at https://ubuntuforums.org/showthread.php?t=2484426&p=14135182#post14135182