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

[Lee Trager]

I just tried retesting with grub-efi-
amd64-signed_1.169+2.04-1ubuntu45_amd64.deb and shim-
signed_1.47+15.4-0ubuntu2_amd64.deb from Impish. I made sure those
versions of GRUB and the shim were served by MAAS and that they were
both used in the local deployed environment. During testing I added 'set
debug="all"' to grub.cfg coming from MAAS as well as the local grub.cfg.
I also made sure 'earlyprintk=efi' was passed to the kernel in the local
grub.cfg.

I don't think the kernel is ever being loaded. The last message I get is
"EFI stub: UEFI Secure Boot is enabled." The system then hangs and never
proceeds.

** Attachment added: "lxd-vm.log.xz"
   https://bugs.launchpad.net/maas/+bug/1865515/+attachment/5495355/+files/lxd-vm.log.xz

-- 
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/1865515

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

Status in MAAS:
  Triaged
Status in OEM Priority Project:
  Confirmed
Status in shim:
  New
Status in grub2 package in Ubuntu:
  Fix Released
Status in shim-signed package in Ubuntu:
  Triaged
Status in grub2 source package in Focal:
  Fix Released
Status in shim-signed source package in Focal:
  Triaged
Status in grub2 source package in Groovy:
  Fix Released
Status in shim-signed source package in Groovy:
  Triaged

Bug description:
  [Impact]

   * UEFI Grub currently doesn't support exiting with an unsuccessful
  exit code. That means, a booted grub cannot determine that it should
  not be booting, exit, remove the installed shim protocol and ask the
  firmware to boot the next BootOrder BootEntry. Without this support
  livecd grub.cfg cannot perfrom "boot from local harddrive" or grub
  booted over the network cannot exit to continue regular boot off the
  harddrive, whilst preserving SecureBoot.

  [Test Case]

   * On a regular Ubuntu install, with UEFI and SecureBoot on, upgrade to new grub2 from proposed.
   * Insert any Ubuntu installation CD as cdrom or usb-stick.
   * Add a new UEFI boot entry for the CD or the usb-stick using efibootmgr, or by using your firmware settings (sudo systemctl reboot --firmware-setup)
   * Make sure the regular Ubuntu install is the first in the BootOrder, followed by the cdrom/usb-stick.
   * Start regular boot, interrupt it with Esc, and enter the grub shell by pressing 'c'
   * Check that the new version of grub is running by doing
   * echo "${package_version}"
   * Next type `exit 1`
   * The current boot should reset and the boot off the installation media should proceed
   * The grub menu options will look different
   * Complete the boot, observe that one ended up in the livecd / installer environment and that secureboot is on by checking the output of `bootctl`.

  [Where problems could occur]

   * `exit` command of grub has changed to accept optional arguments
  that are no-op on all platforms, but uefi as that's the only one that
  supports passing return status. However some might attempt to use this
  on non-uefi platforms in vain. Previously exit command accepted no
  arguments. One might start rely on this functionality whilst using
  mismatched grubs - for example this is not available in Debian or
  Upstream, but is starting to be available in Ubuntu and has been
  available in Fedora/CentOS for a while now. No regular boot flows use
  `exit` command to boot.

  [Other Info]
   
   * Original bug report:

  
  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