Created attachment 2084204 [details] shim with info message "boot option restored" Description of problem: Fedora 42 Workstation Live ISO (Final?, downloaded from https://kojipkgs.fedoraproject.org/compose/42/Fedora-42-20250409.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-42-1.1.x86_64.iso) manipulates EFI without permission Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. Download Fedora 42 Workstation or KDE live ISO 2. Burn it on a USB Drive or mount it in a VM with UEFI, KVM for Example 3. Boot from the ISO or USB - a Hard Drive is not required in this demonstration. 4. check the Output from efibootmgr, Boot0002 is the object of interest in this case: liveuser@localhost-live:~$ efibootmgr BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0002,0001,0000 Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331) Boot0001* UEFI QEMU DVD-ROM QM00001 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0){auto_created_boot_option} Boot0002* Fedora PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/CDROM(1,0x11a2c2,0xf000)/\EFI\fedora\shimx64.efi liveuser@localhost-live:~$ Actual results: SHIM Prints a blue warning screen, with a five second timer. If the timer reaches zero, an EFI Boot entry will be added and the machine will restart. If you press a key during the countdown, shim prints the message:"boot option restored" Expected results: A LIVE ISO/CD/DVD/USB should NEVER touch a running system. It is expected to boot the Live media. Additional info: It looks like the Silverblue Edition is not affected, so i compared both EFI directory Structure. The Fedora Workstation LIVE ISO shows some extra Directories and Files in it. Let's compare: 1. This is the /EFI Content from Fedora Silverblue 42 ISO, downloaded from https://kojipkgs.fedoraproject.org/compose/42/Fedora-42-20250409.0/compose/Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-42-1.1.iso: Fedora-SB-ostree-x86_64-42/EFI$ tree . └── BOOT ├── BOOT.conf ├── BOOTIA32.EFI ├── BOOTX64.EFI ├── fonts │ └── unicode.pf2 ├── grub.cfg ├── grubia32.efi ├── grubx64.efi ├── mmia32.efi └── mmx64.efi 3 directories, 9 files 2. And now, the Fedora Workstation 42 Live ISO Fedora-WS-Live-42/EFI$ tree . ├── BOOT │ ├── BOOTIA32.EFI │ ├── bootx64.efi │ ├── BOOTX64.EFI │ ├── fbia32.efi │ ├── fbx64.efi │ ├── grub.cfg │ ├── grubx64.efi │ └── mmx64.efi └── fedora ├── BOOTIA32.CSV ├── BOOTX64.CSV ├── gcdia32.efi ├── gcdx64.efi ├── grub.cfg ├── grubia32.efi ├── grubx64.efi ├── mmia32.efi ├── mmx64.efi ├── shim.efi ├── shimia32.efi └── shimx64.efi 3 directories, 20 files please note the extra bootx64.efi in the BOOT directory - it is actually the same binary compared to BOOTX64.EFI. And an extra fedora directory inside /EFI This bug may even have security implications as it creates an entry that a user may not be aware of, so I set the severity to high. Thanks.
It also happens on the XFCE shim beta version, but without the message. Thus the proper component is probably whatever program is used to create the iso files and not the shim component per se. It is actually the existence of EFI/BOOT/fbx64.efi which causes this.
yeah, a quick and dirty test in a KVM reveals removing those extra-file will fix the issue. my EFI tree in the "patched" ISO now looks like this: liveuser@localhost-live:/run/media/liveuser/8B00-10CD/EFI$ tree . └── BOOT ├── BOOTIA32.EFI ├── BOOTX64.EFI ├── grub.cfg ├── grubx64.efi └── mmx64.efi 2 directories, 5 files liveuser@localhost-live:/run/media/liveuser/8B00-10CD/EFI$
Yeah, it looks like someone wrote their own stuff from scratch to build the boot image instead of using the existing lorax templates, and they put fbx64.efi where it doesn't belong.
I don't think there are actually any security implications here.
The lives are built with kiwi these days. Not sure if this is an issue in the tool or the templates, but either way the bug needs to go to Neal, and assigning it to kiwi will do that.
I guess there needs to be some kind of filtering mechanism available in kiwi for what stuff goes into an ISO's boot volume. Right now, one does not exist.
I confirmed the behavior on my Lenovo X13, dual booting with Windows 11. I was concerned adding the extra boot entry could break the TPM measurements used by Windows Bitlocker, but in my setup it was fine. I do have a useless "Fedora" boot entry left over in the EFI boot settings that references the USB drive. This is confusing because I already have another "Fedora" boot entry which is a second partition on my SSD.
worth noting, for some reason, this doesn't always happen. I have a test box which I run various test installs on around release time, I did multiple UEFI boots of workstation live from a USB key and never saw this shim screen. this looks like the magic which is supposed to 'recover' installed Fedora UEFI systems if we hit fallback path boot on the disk Fedora is installed to, right, Peter? Any idea what might be causing that to kick in, but only sometimes?
Filed an upstream kiwi bug requesting a filter mechanism: https://github.com/OSInside/kiwi/issues/2777
Hmm. Poking through the code myself - https://github.com/rhboot/shim/blob/main/fallback.c - one thing does stand out: I think we only get the interactive blue screen if TPM is enabled. But we hit the boot manager editing codepaths whether or not TPM is there, I think. The blue screen stuff is around line 1136, after `#ifndef FALLBACK_NONINTERACTIVE`, which only happens if we find TPM at line 1126. But the menu editing happens in `update_boot_order`, which is called by `find_boot_options`, which happens a bit earlier, line 1119. There are various early bailouts in update_boot_order and find_boot_options which *could* prevent the edit happening, I guess, but the intent seems to be that it should happen any time we wind up in this executable at all. It definitely seems pretty clear that we do *not* want the EFI executable built from fallback.c to be on live media at all, and we definitely don't want it to be the thing that gets booted by default. The 'thing that gets booted by default' should be EFI/BOOT/BOOTX64.EFI (on an x86_64 system), which on the live image isn't the same thing as fbx64.efi , at least they're different sizes. I've forgotten exactly how that's set up. Is BOOTX64.EFI just a slightly bigger version of fbx64.efi ? Does it *run* fbx64.efi ? I don't remember.
yeah, now I know what I'm looking for, I can reproduce this on a standard virt-manager UEFI VM, and on my test box. Both get extra "Fedora" EFI boot manager entries just from booting an F42 Workstation live, but not the blue screen (because they don't have TPM). I had actually noticed multiple 'Fedora' boot manager entries on my test box, but it has a pretty screwy UEFI firmware that duplicates things sometimes, and two installs of Fedora on hard disks, so I kinda assumed it was just some fallout from that mess, not something F42 lives were causing :(
Ah. https://github.com/rhboot/shim/blob/main/README.fallback explains how this works. Basically, BOOTX64.EFI is shim; it checks whether it's been started 'normally' or via fallback path. If it was started via the fallback path, and the fallback executable is present, it calls the fallback executable. otherwise, it runs grub. (AIUI).
Pull request for fixing this: https://github.com/OSInside/kiwi/pull/2778
Common Issue description: https://discussion.fedoraproject.org/t/common-issue/148774
FEDORA-EPEL-2025-32f0fcbf72 (kiwi-10.2.16-4.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-32f0fcbf72
FEDORA-EPEL-2025-87fbc68a94 (kiwi-10.2.16-4.el10_1) has been submitted as an update to Fedora EPEL 10.1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-87fbc68a94
FEDORA-2025-eb02bf6686 (kiwi-10.2.16-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-eb02bf6686
FEDORA-2025-27dbfcb5f9 (kiwi-10.2.16-4.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2025-27dbfcb5f9
FEDORA-2025-03e4e6c0cf (kiwi-10.2.16-4.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-87fbc68a94 (kiwi-10.2.16-4.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-27dbfcb5f9 (kiwi-10.2.16-4.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-656865fea1 (kiwi-10.2.16-4.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-eb02bf6686 (kiwi-10.2.16-4.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-32f0fcbf72 (kiwi-10.2.16-4.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-abc2389dd4 (kiwi-10.2.18-1.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-abc2389dd4
FEDORA-2025-b9ae42c8d7 (kiwi-10.2.18-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2025-b9ae42c8d7
FEDORA-EPEL-2025-1516ba47ea (kiwi-10.2.18-1.el10_1) has been submitted as an update to Fedora EPEL 10.1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-1516ba47ea
FEDORA-2025-caba97efbd (kiwi-10.2.18-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-caba97efbd
FEDORA-EPEL-2025-a6bd816644 (kiwi-10.2.18-1.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-a6bd816644
FEDORA-2025-7cf125b833 (kiwi-10.2.18-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7cf125b833
FEDORA-2025-caba97efbd (kiwi-10.2.18-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-7cf125b833 (kiwi-10.2.18-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-1516ba47ea (kiwi-10.2.18-1.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-b9ae42c8d7 (kiwi-10.2.18-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-a6bd816644 (kiwi-10.2.18-1.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-abc2389dd4 (kiwi-10.2.18-1.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.