** Description changed: [Impact] Removable media fail to boot on some machines due to garbage in firmware generated boot entries. This is a regression from LP: #1929471 introduced in shim 15.4-0ubuntu7. In addition we also cherry-pick https://github.com/rhboot/shim/pull/365 to fix a potential buffer overflow. + + In addition we also cherry-pick https://github.com/rhboot/shim/pull/396 + to fix possible firmware corruption in the fallback loader due to out- + of-bounds access to the boot order array. [Test plan] I'm sure someone can test a new daily impish ISO on an affected machine. Verification is not necessary for individual SRU releases. We will also do boot of an installed system, and perform the usual chainloaded netbooting test, prior to uploading. [Regression potential] - We'll apply three patches for the main issue: + We'll apply four patches for the main issue: Patches 1/2 (https://github.com/rhboot/shim/pull/393) add a fallback to the default loader (with 2s timeout) if we failed to load any specified loader. This ensures we can always boot our default loader, and hence installed systems, even if there is garbage around. It also adds debugging output for the load option that is being parsed, such that people can debug why it failed. - Patch 3 (https://github.com/rhboot/shim/pull/399) disables parsing load - options entirely when booting via the removable media path (boot*.efi). - This means that any system where admins generate boot entries like - bootx64.efi fwupdx64.efi to load a specific second stage will fail to - load that second stage and load grubx64.efi instead. + Patches 3 and 4 (https://github.com/rhboot/shim/pull/399) disables + parsing load options entirely when booting via the removable media path + (boot*.efi). This means that any system where admins generate boot + entries like bootx64.efi fwupdx64.efi to load a specific second stage + will fail to load that second stage and load grubx64.efi instead. is this a problem in practice? On installed systems, we install \EFI\BOOT\bootx64.efi in addition to \EFI\ubuntu\shimx64.efi, and generate boot loader entries for the latter. The former will always use the fbx64.efi fallback loader to add missing boot loader entries and load grub, hence it doesn't seem to support custom options anyway (you'd have to delete fbx64.efi; and even then - you still have the shimx64.efi binary). On installer media, we do not expect you to specify another second stage loader anyway. It's arguably only problematic there, as those could be read-only and hence you can't rename the binary to shimx64.efi. For the overflow, the fix is trivially correct. + For the fallback loader, the fix is reasonably trivial; regression + potential there could be failure to add a boot entry which is not super + critical. + [Original bug report] Testing Ubuntu Impish daily ISO= http://cdimage.ubuntu.com/daily-live/20210721/impish-desktop-amd64.iso The test machines are: 1. Dell [ Optiplex] MT 7040 i7-6700 booting in UEFI mode 2. Dell [ Optiplex] MT 7060, i7-8700 booting in UEFI+secure boot mode Boot from USB media fails with the message: Failed to open /EFI/boot/? invalid parameter No further info available
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1937115 Title: Unable to boot/install Impish daily in UEFI boot mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cd-boot-images-amd64/+bug/1937115/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
