[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

[Steve Langasek]

On Tue, May 19, 2020 at 08:59:46PM -0000, Lee Trager wrote:
> Based on the MAAS logs the halt happens after the remote shim, grub, and
> grub.cfg have been loaded. I didn't see anything in the console to show
> grub running but it may have been cleared before I could see it.

> Console output:

> Booting local disk...
> Failed to open \efi\boot\grubx64.efi - Not Found
> Failed to load image \efi\boot\grubx64.efi: Not Found
> start_image() returned Not Found


> Bootloader has not verified loaded image.
> System is compromised.  halting.

Doesn't this output show that it has successfully chained to the local shim,
since it's shim that is loading \efi\boot\grubx64.efi and those messages are
from shim?

What I don't currently understand is why this should behave any differently
with or without SecureBoot enabled; that will need digging into.  But the
specific error "Not found" certainly implies there is a difference in the
path resolution when secureboot is on.

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

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

Status in MAAS:
  Confirmed
Status in grub package in Ubuntu:
  Confirmed
Status in shim-signed package in Ubuntu:
  Confirmed

Bug description:
  MAAS (2.4.2 and 2.6.2) cannot deploy to a server with Secure Boot
  active. This appears to be a regression of bug #1711203; the symptoms
  are identical. Namely:

  1) The system can begin deployment fine.
  2) After deployment is complete except for the final reboot, the
     system will reboot.
  3) GRUB appears briefly on the screen.
  4) The system console briefly displays the message:
     Bootloader has not verified loaded image
     System is compromised.  halting.
  5) The node powers off.
  6) Eventually MAAS times out on the deployment and declares
     that it's failed.

  I've verified this on three MAAS servers and one node each (jehan, a
  Quanta QuantaGrid D52B-1U in 18T; capella, a Supermicro SYS-6028U-TR4+
  in 1SS, and brennan, an Intel NUC DC53427HYE on my home network).

  Two of the MAAS servers are running MAAS
  2.6.2-7841-ga10625be3-0ubuntu1~18.04.1; the third is on
  2.4.2-7034-g2f5deb8b8-0ubuntu1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions