group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1689687@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.12

---------------
grub2 (2.02~beta2-36ubuntu3.12) xenial; urgency=medium

  * debian/patches: Rework linuxefi/SecureBoot support and sync with upstream
    SB patch set: (LP: #1696599)
    - linuxefi_backport_arm64.patch: backport basic arm64 chainload/linux
      command support from 17.04.
    - linuxefi_arm_sb_support.patch: add Secure Boot support for arm for its
      chainloader.
    - linuxefi_fix_validation_race.patch: Fix a race in validating images.
    - linuxefi_chainloader_path.patch: honor the starting path for grub, so
      images do not need to be started from $root.
    - linuxefi_chainloader_sb.patch: Fix some more issues in chainloader use
      when Secure Boot is enabled.
    - linuxefi_loaders_enforce_sb.patch: Enforce Secure Boot policy for all
      loaders: don't load the commands when Secure Boot is enabled.
    - linuxefi_re-enable_linux_cmd.patch: Since we rely on the linux and
      initrd commands to automatically hand-off to linuxefi/initrdefi; re-
      enable the linux loader.
    - linuxefi_chainloader_pe_fixes.patch: PE parsing fixes for chainloading
      "special" PE images, such as Windows'.
    - linuxefi_rework_non-sb_cases.patch: rework cases where Secure Boot is
      disabled or shim validation is disabled so loading works as EFI binaries
      when it is supposed to.
    - Removed linuxefi_require_shim.patch; superseded by the above.
      (LP: #1689687)
  * debian/patches/git_tsc_use_alt_delay_sources_d43a5ee6.patch: refreshed.
  * debian/patches/arm64-set-correct-length-of-device-path-end-entry.patch:
    dropped; included in linuxefi_backport_arm64.patch.

 -- Mathieu Trudel-Lapierre <cyphermox@xxxxxxxxxx>  Thu, 08 Jun 2017
10:16:17 -0700

** Changed in: grub2 (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1689687

Title:
  pass validation if shim protocol is not installed

Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Xenial:
  Fix Released
Status in grub2 source package in Yakkety:
  Won't Fix
Status in grub2 source package in Zesty:
  Fix Released
Status in grub2 source package in Artful:
  Fix Released

Bug description:
  [Impact]
  Users of UEFI Secure Boot that must disable SB validation in shim, for example to run dkms modules, may notice that the kernel incorrectly reports the SecureBoot/shim states.

  [Test case]
  1) Install bbswitch-dkms

  a) Validate whether you are prompted to disable Secure Boot. If Secure
  Boot is already disabled, you should not be prompted again. If it
  isn't, you should be prompted once.

  b) If shim validation was previously disabled, verify that the kernel
  reports /proc/sys/kernel/moksbstate_disabled as "1" (shim validation
  disabled)

  [Regression Potential]
  This affects the loading behavior for the kernel, which will now load as an EFI binary and thus execute some extra code to bring up UEFI, which would otherwise not get loaded in the case shim validation is disabled. Given that the system must have booted successfully once for validation to get disabled, there should not be any issues; but possible resulting regressions would be a failure to correctly load the kernel, or a kernel issue early on during boot. Furthermore, any instance where the incorrect loading behavior was relied upon by installs (though I can think of no examples for this) would regress. The kind of issue that might be seen there is where code relies on /proc/sys/kernel/moksbstate_disabled or /proc/sys/kernel/secure_boot, or on other aspects of the kernel's secure boot policy (there seems to exist at least one special case for SB in kernel bluetooth code), the programs that rely on such behavior would regress. There are no packages shipped in Ubuntu that rely on this incorrect behavior; the only known package to ship something that checks the relevant /proc files is shim-signed, and this is meant to correct the behavior when these values are set.

  
  ---

  GRUB currently fails SecureBoot validation (ie. calls to
  grub_linuxefi_secure_validate() fail) if shim's protocol is not
  installed when that function is called.

  This currently breaks some kernel features relying on starting in the
  EFI stub code (ie. the kernel being loaded as an EFI binary); and
  instead falls back to the 'linux' command instead of 'linuxefi'.

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