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

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.