pass validation if shim protocol is not installed

Bug #1689687 reported by Mathieu Trudel-Lapierre on 2017-05-10
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Status tracked in Artful
Xenial
Undecided
Unassigned
Yakkety
Undecided
Unassigned
Zesty
Undecided
Unassigned
Artful
Undecided
Unassigned

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'.

All this can be trivially done by disabling debian/patches/linuxefi_require_shim.patch. I got some historical rationale from Colin already as to why it was added (and marked temporary at the time); and it seems to me like we can just remove it.

As for a previous question about whether this would affect arm64: it would not; this is only for i386 (well, x86_64-efi, since that's all we support).

Changed in grub2 (Ubuntu Artful):
status: New → In Progress

grub2 (2.02~beta3-4ubuntu4) artful; urgency=medium

  * debian/patches: Rework linuxefi/SecureBoot support and sync with upstream
    SB patch set:
    - 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.

Changed in grub2 (Ubuntu Artful):
status: In Progress → Fix Released
description: updated

Hello Mathieu, or anyone else affected,

Accepted grub2 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-36ubuntu3.12 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in grub2 (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed
Chris Halse Rogers (raof) wrote :

Hello Mathieu, or anyone else affected,

Accepted grub2 into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-36ubuntu11.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in grub2 (Ubuntu Yakkety):
status: New → Fix Committed
Changed in grub2 (Ubuntu Zesty):
status: New → Fix Committed
Chris Halse Rogers (raof) wrote :

Hello Mathieu, or anyone else affected,

Accepted grub2 into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02~beta3-4ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

As part of a recent change in the Stable Release Update verification policy we would like to inform that for a bug to be considered verified for a given release a verification-done-$RELEASE tag needs to be added to the bug where $RELEASE is the name of the series the package that was tested (e.g. verification-done-xenial). Please note that the global 'verification-done' tag can no longer be used for this purpose.

Thank you!

Verification-done on xenial using grub2 2.02~beta2-36ubuntu3.12:

/proc/sys/kernel/moksbstate_disabled reads 1 when shim validation is disabled (as expected given this update). Prompting is correctly done when installing a new DKMS module with Secure Boot validation in shim enabled; and no prompting happens when validation is already disabled.

tags: added: verification-done-xenial

As a part of the Stable Release Updates quality process a search for Launchpad bug reports using the version of grub2 from zesty-proposed was performed and bug 1701681 was found. Please investigate this bug report to ensure that a regression will not be created by this SRU. In the event that this is not a regression remove the "verification-failed" tag from this bug report and add the tag "bot-stop-nagging" to bug 1701681 (not this bug). Thanks!

tags: added: verification-failed

As a part of the Stable Release Updates quality process a search for Launchpad bug reports using the version of grub2 from xenial-proposed was performed and bug 1705946 was found. Please investigate that bug report to ensure that a regression will not be created by this SRU. In the event that this is not a regression remove the "verification-failed" tag from this bug report and add the tag "bot-stop-nagging" to bug 1705946 (not this bug). Thanks!

Verification-done on zesty using grub2 2.02~beta3-4ubuntu2.2:

Shim state when disabled is now correctly tracked in /proc/sys/kernel/moksbstate_disabled; as the system boots in the UEFI code paths even when shim validation is disabled.

tags: added: verification-done-zesty
removed: verification-failed verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 2.02~beta3-4ubuntu2.2

---------------
grub2 (2.02~beta3-4ubuntu2.2) zesty; urgency=medium

  * debian/patches: Rework linuxefi/SecureBoot support and sync with upstream
    SB patch set: (LP: #1696599)
    - 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)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 14 Jun 2017 14:44:48 -0400

Changed in grub2 (Ubuntu Zesty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for grub2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Steve Langasek (vorlon) on 2017-07-28
Changed in grub2 (Ubuntu Yakkety):
status: Fix Committed → Won't Fix
Launchpad Janitor (janitor) wrote :

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 <email address hidden> Thu, 08 Jun 2017 10:16:17 -0700

Changed in grub2 (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers