grub2 isn't responsible for updating DBX - fwupd is.  Nor is BOOTX64.EFI, which is part of shim.

> blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/EFI/BOOT/BOOTX64.EFI Authenticode checksum [0ce02100f67c7ef85f4eed368f02bf7092380a3c23ca91fd7f19430d94b00c19] is present in dbx

Did you ensure that grub and shim are up to date?  What fwupd is telling you is that if you apply the DBX update, your system will be unbootable because you have a version of shim that is outdated installed on your system.  You need to update it.

> awarda@fedora:~$ grub2-set-default --version
> grub2-set-default (GRUB) 2.06

Like most tools, this tells you the upstream release, not the actual component version.  It's also not the right package.  A more useful command would be something like `rpm -qv shim-x64`, or if you don't know the package it comes from, `rpm -qf /boot/efi/EFI/BOOT/BOOTX64.EFI`, both of which yield a result like "shim-x64-15.6-2.x86_64".

There is no rpm package manager in Silverblue, this fedora variant is ostree based. 
Thus grub2 & shim would have to be updated with an atomic rpm-ostree update:

warda@fedora:~$ rpm-ostree status -b
State: idle
BootedDeployment:
● fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220919.0 (2022-09-19T00:44:56Z)
               BaseCommit: a36d2542999f5e374772e1b34abeee25e102a771be4905a564f118feb21033e4
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
          LayeredPackages: f33-backgrounds-base.noarch f33-backgrounds-extras-base.noarch
                           f33-backgrounds-extras-gnome.noarch f33-backgrounds-gnome.noarch gnome-tweaks
                           google-chrome-stable igt-gpu-tools libguestfs-tools libvirt libvirt-daemon-config-network
                           libvirt-daemon-kvm libvirt-nss python3-libguestfs qemu-kvm virt-install virt-manager
                           virt-top virt-viewer

awarda@fedora:~$ rpm-ostree db list a36d25 |grep -E "shim|grub"
 grub2-common-1:2.06-53.fc36.noarch
 grub2-efi-ia32-1:2.06-53.fc36.x86_64
 grub2-efi-x64-1:2.06-53.fc36.x86_64
 grub2-pc-1:2.06-53.fc36.x86_64
 grub2-pc-modules-1:2.06-53.fc36.noarch
 grub2-tools-1:2.06-53.fc36.x86_64
 grub2-tools-minimal-1:2.06-53.fc36.x86_64
 grubby-8.40-67.fc36.x86_64
 ostree-grub2-2022.5-2.fc36.x86_64
 shim-ia32-15.6-2.x86_64
 shim-x64-15.6-2.x86_64

This is https://github.com/fedora-silverblue/issue-tracker/issues/120. Workaround is to update manually from the content of /usr/lib/ostree-boot/.
Hopefully soon (F38) we will have bootupd for Silverblue (see issue above).

Timothée, are you proposing this?

sudo cp /usr/lib/ostree-boot/efi/EFI/BOOT/*64* /boot/efi/EFI/BOOT/

---

awarda@fedora:~$ sudo ls -la /usr/lib/ostree-boot/efi/EFI/BOOT/
total 1820
drwx------.  1 root root     84  1. Jan 1970  .
drwxr-xr-x.  1 root root     20  1. Jan 1970  ..
-rwx------.  7 root root 742064  1. Jan 1970  BOOTIA32.EFI
-rwx------. 10 root root 946712  1. Jan 1970  BOOTX64.EFI
-rwx------.  4 root root  70776  1. Jan 1970  fbia32.efi
-rwx------.  4 root root  90280  1. Jan 1970  fbx64.efi

awarda@fedora:~$ sudo rpm -qf /usr/lib/ostree-boot/efi/EFI/BOOT/BOOTX64.EFI
file /usr/lib/ostree-boot/efi/EFI/BOOT/BOOTX64.EFI is not owned by any package

awarda@fedora:~$ sudo ls -la /boot/efi/EFI/BOOT/
total 1544
drwx------. 2 root root    4096  1. Jan 1980  .
drwx------. 4 root root    4096  1. Jan 1980  ..
-rwx------. 1 root root 1210776  1. Jan 1980  BOOTX64.EFI
-rwx------. 1 root root  357248  1. Jan 1980  fbx64.efi

awarda@fedora:~$ sudo rpm -qf /boot/efi/EFI/BOOT/BOOTX64.EFI
shim-x64-15.6-2.x86_64

I created a 'fedora-new' directory as a copy of /usr/lib/ostree-boot/efi/EFI/fedora from which I deleted ia32 files, ending up here:

# ls fedora*
fedora:
BOOTX64.CSV  fonts  fw  fwupdx64.efi  grub.cfg  grub.cfg.old  grubenv  grubx64.efi  mmx64.efi  shim.efi  shimx64.efi  shimx64-fedora.efi

fedora-new:
BOOTX64.CSV  grubx64.efi  mmx64.efi  shim.efi  shimx64.efi

so apart from fonts/ and fw/ subdirectories and grub configs, new dir is missing fwupdx64.efi and shimx64-fedora.efi. Will the system be able to boot 1) with old versions of them, or 2) without them?

(In reply to Timothée Ravier from comment #3)
> Hopefully soon (F38) we will have bootupd for Silverblue (see issue above).

Given that:
* this is now equivalent of leaving CVEs unfixed in three active branches (IIUC 36, 37 and pre-bootupd 38)
* the workaround is neither straightforward nor obvious even for people with some experience
* SB is frequently deployed as hard-to-break system that is trusted to update itself safely so users who can not manage their computers are secure as far as system allow
* this issue is first of its kind in 10 years
we need some sort of hotfix sooner than later...

Fedora 38 is way too late.

The DBX update is a security update.  It prohibits booting known-vulnerable systems.  The shim update to 15.6 is also CVE fix.

Leaving released fedoras without a path to apply security updates isn't workable - they need to have these applied.

Bigger picture, a problem is that we've let Fedora Silverblue, IoT and CoreOS drift.  We deployed bootupd on FCOS some time ago for this, and as of recently it's been added to F38SB, but not IoT.

It's trivial to backport to earlier branches, I started that at
https://pagure.io/workstation-ostree-config/pull-request/303

(Hmm, actually it looks like the earlier PR was missing some wiring up at the build side, specifically we need this bit https://github.com/coreos/fedora-coreos-config/blob/e9ea2831f41bfb5456312774ba79649b1d2c25e1/manifests/bootupd.yaml#L6 )

Once it's shipped there we'll do a bit of testing and document how to turn it on.

When we're talking about security though, bear in mind that this is a consequence of us making *every other upgrade* transactional and safe.  I've lost track of how many people I've seen have their laptop run out of battery or a kernel panics (or more fun, something takes down the desktop during live updates which kills the terminal running traditional yum/dnf) and then they have a half-updated broken system and they learn to fear operating system updates - and avoid doing it often.

The reason bootupd isn't on by default is because we haven't proven out transactional bootloader updates.  Which means doing so particularly on a desktop system should have a screen like one sees on other operating systems that says e.g. "Please don't turn off your computer" if we were doing it correctly.  (But better of course to make it transactional!)

This bug got filed against rpm-ostree, but it's really more of a bug against "image based updates", of which rpm-ostree is just one mechanism.  (We've tried to avoid tightly tying together rpm-ostree and bootupd too, although they clearly could use better integration even)

I'd say again going back to the top the root issue is drift between our various image-based systems, and I've got some work in the background to address that.

Thanks, Colin, for explaining the direction in detail

I have to agree with others that it is getting increasingly uncomfortable
still not being able to apply firmware updates on Silverblue.

(In reply to Colin Walters from comment #8)
> Once it's shipped there we'll do a bit of testing and document how to turn
> it on.

How close are we now to be able to do this for F37SB users? :)

I share this info in case is useful. A few days ago, my Intel motherboard died and I chose as replacement the ASRock B550M PG Riptide, with AMD Ryzen 7 5700G with Radeon. This is Fedora Silverblue 37. Everything worked OK, except that I was hit by this same bug.

Do I interpret the efibootmgr output below correctly, that only these three files are accessed from the local drive during boot, and that BOOTX64.EFI is not accessed at all during boot of my Fedora 37 Silverbue?

awarda@fedora:~$ efibootmgr -v|grep File|grep HD
Boot0000* Red Hat Enterprise Linux HD(1,GPT,26a6453f-d383-47f6-a1d3-35ad8bc99513,0x800,0x64000)/File(\EFI\redhat\shimx64.efi)
Boot0001* Fedora HD(1,GPT,a774f63b-e5e4-4a3c-9712-a6785d68cfa1,0x800,0x12c000)/File(\EFI\fedora\shimx64.efi)
Boot0002* Linux-Firmware-Updater HD(1,GPT,a774f63b-e5e4-4a3c-9712-a6785d68cfa1,0x800,0x12c000)/File(\EFI\fedora\fwupdx64.efi)

Is the \EFI\redhat\ a potential left-over from my previous, deleted RHEL installation on this disk?

It looks like my Fedora 37 Silverblue and the Firmware Updater use the directory \EFI\fedora\ instead.

Thus it should be safe for me to delete /boot/efi/EFI/BOOT/BOOTX64.EFI in my Fedora 37 Silverblue?

Suggestion: instead of complaining about outdated, unused EFI files, fwupdmgr chould try to determine which EFI files are in (multi-) boot sequences and only complain about EFI files that are actually used.

While people work on fixing this, can anyone confirm that Armin's suggestion from https://bugzilla.redhat.com/show_bug.cgi?id=2127995#c5 is good as a workaround? I'm 99% sure it is, but it would be good to have confirmation. We should at least document this on Common Bugs, as it's likely more and more users will be affected by it as time goes on and vendors update their revocation lists.

I see there's also a workaround suggested in the silverblue issue: https://github.com/fedora-silverblue/issue-tracker/issues/120#issuecomment-1177515110 . Not sure which one would be better to document.

Looking around in my f37 Silverblue, I found the ostree-grub2-2022.6-1.fc37.x86_64 RPM installed. This seems to be taking care of updating GRUB in an OSTREE (vs. regular RPM) based Fedora system via /etc/grub.d/15_ostree. 

Could we do something similar for shim, fwupd, and the other EFI stuff, automatically updating the stuff in /boot/efi/EFI/ from /usr/lib/ostree-boot/efi/EFI?

Well, that's more or less what switching to bootupd will achieve. bootupd is replacing ostree-grub2 , and will solve this problem and maybe some others.

curious: will f38 switch to bootupd and solve this problem?

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Sounds like this is probably still current.

Is there a verified/sanctioned work-around for this in F38 SSB or do we just wait to rebase? Feels wierd yo have updates pending for this long.

(In reply to DaveG from comment #19)
> Is there a verified/sanctioned work-around for this in F38 SSB or do we just
> wait to rebase? Feels wierd yo have updates pending for this long.

On the upstream Silverblue issue, there is a workaround that appears to be useful - https://github.com/fedora-silverblue/issue-tracker/issues/120#issuecomment-1177515110

I don't believe that has been fully tested/verified, but it looks promising.

Thanks for the info - Nice to get back to the command-line for a while! executed, rebooted and now Gnome Software is clean again.

--DaveG

Oops - posted too soon - secure dbx still refuses to update either from Gnome Software or fwupd. same output. Ho, hum. Guess I'll wait a little longer.

I'm on Fedora 38 and still unable to update.

lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	Fedora
Description:	Fedora release 38 (Thirty Eight)
Release:	38
Codename:	ThirtyEight

sudo fwupdmgr update
Devices with no available firmware updates: 
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • USB2.0 Hub
 • USB2.0 Hub
 • USB3.1 Hub
 • USB3.1 Hub
Devices with the latest available firmware version:
 • Battery
 • Embedded Controller
 • Integrated Camera
 • Intel Management Engine
 • System Firmware
 • ThinkPad Thunderbolt 3 Dock
 • ThinkPad Thunderbolt 3 Dock USB Audio
 • VMM5322 inside ThinkPad Thunderbolt 3 Dock
 • msp430
 • MZVL2512HCJQ-00BL7
╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 190 to 371?                                            ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ Insecure versions of the Microsoft Windows boot manager affected by Black    ║
║ Lotus were added to the list of forbidden signatures due to a discovered     ║
║ security problem.This updates the dbx to the latest release from Microsoft.  ║
║                                                                              ║
║ 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.Applying this update may also cause     ║
║ some Windows install media to not start correctly.                           ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝
Perform operation? [Y|n]: 
Decompressing…           [                                       ]
Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/EFI/redhat/shimx64-redhat.efi Authenticode checksum [835881f2a5572d7059b5c8635018552892e945626f115fc9ca07acf7bde857a4] is present in dbx

Any movement on this? now well in to F39.

F40 and later will use bootupd and so should have this fixed. For F39 and earlier there will only be the workarounds, I think.

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Colin, what do you want to do with this? Obviously we're shipping somewhat newer boot images in newer releases, but the fundamental problem that the bootloader on an installed atomic system is never updated is still true, AIUI. do we need this bug to track it?

Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

*** This bug has been marked as a duplicate of bug 2150982 ***

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days