[Bug 1937115] Re: Unable to boot/install Impish daily in UEFI boot mode

Thu Aug 5 09:35:08 UTC 2021

** Description changed:

- Testing Ubuntu Impish daily ISO= http://cdimage.ubuntu.com/daily-
- live/20210721/impish-desktop-amd64.iso
+ [Impact]
+ Removable media fail to boot on some machines due to garbage in firmware generated boot entries.
+ 
+ In addition we also cherry-pick https://github.com/rhboot/shim/pull/365
+ to fix a potential buffer overflow.
+ 
+ [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:
+ 
+ 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 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.
+ 
+ [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

** Tags added: regression-update

** Description changed:

  [Impact]
- Removable media fail to boot on some machines due to garbage in firmware generated boot entries.
+ Removable media fail to boot on some machines due to garbage in firmware generated boot entries. This is a regression from LP: #1929471

  In addition we also cherry-pick https://github.com/rhboot/shim/pull/365
  to fix a potential buffer overflow.

  [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:

  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 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.

  [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

** 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
+ 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.

  [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:

  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 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.

  [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

** 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.

  [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:

  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 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.
+ 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.

  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.

  [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
Foundations Bugs, which is subscribed to shim in Ubuntu.
https://bugs.launchpad.net/bugs/1937115

Title:
  Unable to boot/install Impish daily in UEFI boot mode

Status in cd-boot-images-amd64 package in Ubuntu:
  Triaged
Status in shim package in Ubuntu:
  In Progress
Status in cd-boot-images-amd64 source package in Focal:
  Confirmed
Status in shim source package in Focal:
  Confirmed
Status in cd-boot-images-amd64 source package in Impish:
  Triaged
Status in shim source package in Impish:
  In Progress

Bug description:
  [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.

  [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:

  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.

  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.

  [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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cd-boot-images-amd64/+bug/1937115/+subscriptions