[Bug 1864533] Autopkgtest regression report (grub2/2.02-2ubuntu8.15)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted grub2 (2.02-2ubuntu8.15) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

ubuntu-image/1.8+18.04ubuntu2 (s390x)


Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#grub2

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  grub wrongly booting via bios entry point instead of efi when
  secureboot disabled

Status in grub2 package in Ubuntu:
  Fix Committed
Status in grub2 source package in Bionic:
  Fix Committed
Status in grub2 source package in Eoan:
  Fix Committed
Status in grub2 source package in Focal:
  Fix Committed

Bug description:
  [SRU Justification]
  Currently, the Ubuntu patches for secureboot support will boot the kernel via the EFI stub ONLY if secureboot is enabled.  This means that if secureboot is disabled, grub wrongly skips the kernel's EFI stub, resulting in buggy behavior (missing EFI fixups; lack of access to the TCG log).

  When booted on EFI, grub should ALWAYS use the EFI protocol to boot
  the kernel, and only do a non-EFI boot as a fallback if the EFI stub
  is not available AND secureboot is not enabled.

  Patches available at https://people.canonical.com/~chrisccoulson/grub-
  efi-fixes/

  [Test case]
  Boot kernel in secure boot and non-secure boot, check that
  /proc/sys/kernel/bootloader_{type,version} are the same (they'd be different if we booted via grub's own linux loader).

  
  [Regression potential]
  This changes behavior of how grub passes control to Linux kernels when secureboot is disabled on UEFI systems, which can result in arbitrary changes to the boot process up to and including failure to boot if there are bugs in the kernel EFI stub on some platforms.  However, it is generally more correct to boot via the EFI stub and it's expected that most users are booting via the EFI stub on UEFI systems due to the ubiquity of SecureBoot by default on modern hardware, so having consistent behavior whether SecureBoot is on or off is likely to be the less buggy option generally.

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