[Bug 1568128] [NEW] GRUB fails to chainload another EFI loader when Secure Boot is active

[Rod Smith]

Public bug reported:

I'm trying to perform 16.04 server certification work on a Lenovo x3550
M5 server (jolteon in OIL). Part of this task involves ensuring that the
server boots with Secure Boot active. Unfortunately, this has eluded me.
Using MAAS, the server enlists, commissions, and (mostly) deploys
correctly; however, it hangs when it tries to reboot after deployment,
resulting in a deployment failure. Using an SOL session, I see that the
server hangs with the following displayed:

Booting local disk...
/EndEntire
file path: /ACPI(a0341d0,0)/PCI(0,1)/PCI(0,0)/Ctrl(0)/SCSI(0,0)
/HD(15,800,100000,40430285134e224c,2,2)/File(\efi\ubuntu\
/File(shimx64.efi)/EndEntire
error: cannot load image.

Press any key to continue...

Failed to boot both default and fallback entries.

Press any key to continue...

Disabling Secure Boot causes the boot to succeed at this point; and
deploying with Secure Boot disabled works completely.

Further experiments:

- Using a system deployed with Secure Boot inactive, enabling Secure Boot causes the same symptom just reported.
- After deploying with Secure Boot inactive, I added an efibootmgr entry to boot \EFI\ubuntu\shimx64.efi from the hard disk. (Using MAAS, this entry does not normally exist; instead, MAAS relies on a PXE-delivered GRUB that chainloads the disk-based GRUB.) Re-enabling Secure Boot then resulted in a successful boot from the disk-based GRUB.
- In an extension of the previous experiment, I modified /boot/grub/grub.cfg to chainload back to GRUB (two entries, one each to grubx64.efi and shimx64.efi). With Secure Boot re-enabled, these boot options both failed, with symptoms similar to those of MAAS's PXE-based attempt; but when I again disabled Secure Boot, these options both worked.

Overall, the results suggest that GRUB is unable to chainload a second
EFI boot loader with Secure Boot active, although it can launch a Linux
kernel under these conditions. One major caveat is that all of this
works as it should on several other computers. This fact strongly
suggests that the bug is actually with the Lenovo x3550 M5's firmware.
I'm filing this bug report against GRUB in the hopes that it can be
worked around in GRUB (or possibly Shim), or in case it is legitimately
a GRUB or Shim bug.

Note also that these symptoms are very similar to those of bug #1091464.
If the Powers That Be decide this bug is a duplicate, that's fine.

** Affects: grub2 (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1568128

Title:
  GRUB fails to chainload another EFI loader when Secure Boot is active

Status in grub2 package in Ubuntu:
  New

Bug description:
  I'm trying to perform 16.04 server certification work on a Lenovo
  x3550 M5 server (jolteon in OIL). Part of this task involves ensuring
  that the server boots with Secure Boot active. Unfortunately, this has
  eluded me. Using MAAS, the server enlists, commissions, and (mostly)
  deploys correctly; however, it hangs when it tries to reboot after
  deployment, resulting in a deployment failure. Using an SOL session, I
  see that the server hangs with the following displayed:

  Booting local disk...
  /EndEntire
  file path: /ACPI(a0341d0,0)/PCI(0,1)/PCI(0,0)/Ctrl(0)/SCSI(0,0)
  /HD(15,800,100000,40430285134e224c,2,2)/File(\efi\ubuntu\
  /File(shimx64.efi)/EndEntire
  error: cannot load image.

  Press any key to continue...

  Failed to boot both default and fallback entries.

  Press any key to continue...

  Disabling Secure Boot causes the boot to succeed at this point; and
  deploying with Secure Boot disabled works completely.

  Further experiments:

  - Using a system deployed with Secure Boot inactive, enabling Secure Boot causes the same symptom just reported.
  - After deploying with Secure Boot inactive, I added an efibootmgr entry to boot \EFI\ubuntu\shimx64.efi from the hard disk. (Using MAAS, this entry does not normally exist; instead, MAAS relies on a PXE-delivered GRUB that chainloads the disk-based GRUB.) Re-enabling Secure Boot then resulted in a successful boot from the disk-based GRUB.
  - In an extension of the previous experiment, I modified /boot/grub/grub.cfg to chainload back to GRUB (two entries, one each to grubx64.efi and shimx64.efi). With Secure Boot re-enabled, these boot options both failed, with symptoms similar to those of MAAS's PXE-based attempt; but when I again disabled Secure Boot, these options both worked.

  Overall, the results suggest that GRUB is unable to chainload a second
  EFI boot loader with Secure Boot active, although it can launch a
  Linux kernel under these conditions. One major caveat is that all of
  this works as it should on several other computers. This fact strongly
  suggests that the bug is actually with the Lenovo x3550 M5's firmware.
  I'm filing this bug report against GRUB in the hopes that it can be
  worked around in GRUB (or possibly Shim), or in case it is
  legitimately a GRUB or Shim bug.

  Note also that these symptoms are very similar to those of bug
  #1091464. If the Powers That Be decide this bug is a duplicate, that's
  fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1568128/+subscriptions