GRUB's Secure Boot implementation loads unsigned kernel without warning

Bug #1401532 reported by Wouter on 2014-12-11
460
This bug affects 40 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
High
Mathieu Trudel-Lapierre
Trusty
High
Mathieu Trudel-Lapierre
Xenial
High
Mathieu Trudel-Lapierre
Bionic
High
Mathieu Trudel-Lapierre
grub2-signed (Ubuntu)
High
Mathieu Trudel-Lapierre
Trusty
High
Mathieu Trudel-Lapierre
Xenial
High
Mathieu Trudel-Lapierre
Bionic
High
Mathieu Trudel-Lapierre

Bug Description

[Rationale]
GRUB should help us enforce that in UEFI mode, only signed kernels are loaded. It should not silently fall back to loading unsigned kernels.

[Impact]
All our users booting in UEFI; on all supported releases.

[Test cases]

= grub2 =

Booting unsigned kernels:
1) Try to boot a custom kernel
2) Verify that the kernel will not be loaded by grub (you should see an error message about the signature)

Booting signed kernels:
1) Try to boot an official signed kernel (from -release or -updates)
2) Verify that the system boots normally and no warnings are shown about signature.

[Regression Potential]
Any failure to boot presenting as a failure to load the kernel from within grub, with an "invalid signature" type error message or not, should be investigated as a potential regression of this stable update.

---

Me and some other students have conducted some various experiments on Secure Boot enabled machines. The main focus of the tests was to circumvent Secure Boot and load unsigned kernels or kernels that have been signed with other keys.

On your SecureBoot (https://wiki.ubuntu.com/SecurityTeam/SecureBoot) it is outlined that GRUB will boot unsigned kernels when the kernel is unsigned. During one of our experiments it seemed that this statement was true and that GRUB loads unsigned kernels as described on your page. We understand that for various reasons GRUB should still support the use-case when an unsigned kernel must be loaded, but with the current approach the user isn't aware if there is a whole chain of trust. For example, it could still be possible to load some malware before it boots the Operating System itself (bootkits). One of the many reasons that Secure Boot has been developed is to protect the user from these kind of attacks.

With the current approach the purpose of Secure Boot is somewhat defeated, and the user doesn't know if the whole chain has been verified or not. It could easily be the case that an unsigned kernel has been loaded by Ubuntu without the user noticing. From our point of view, a better approach would be to inform the user that an unsigned kernel will be loaded and that the user can make a choice if he/she wants to proceed. The default action could be to accept the option, remember the user's option and sometimes remind the user of the fact that it is loading an unsigned kernel.

This problem is of course related to GRUB itself and not to Ubuntu itself. The reason for filing this bug and informing the SecurityTeam of Ubuntu is to ask for their opinions and what your point of view is on the current approach and to see if other users classify this as a "bug".

GRUB2 versions: grub-2.02~beta2, 1.34.1+2.02~beta2-9ubuntu1
Ubuntu version: Trusty (will also affect newer and older versions, GRUB specific problem)

tags: added: grub2-signed
Marc Deslauriers (mdeslaur) wrote :

Thanks for reporting this.

We aren't currently using SecureBoot for security reasons. Our SecureBoot support is only to allow installation on computers that have it enabled by default.

If we ever in the future rely on SecureBoot as a security measure, I agree a warning would be appropriate.

information type: Private Security → Public Security
Changed in grub2-signed (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
Dimitri John Ledkov (xnox) wrote :

The purpose of SecureBoot is to prevent untrusted modification of firmware, thus as per SecureBoot specs no unsigned code should be called before ExitBootServices() has been called. Thus one should be targetting as to how to bypass that when booted in secure boot mode. For example the King's & Queen's Gambits vulnerabilities as presented in http://www.mitre.org/sites/default/files/publications/14-2221-extreme-escalation-presentation.pdf

Wouter (wouter-miltenburg) wrote :

The presentation is about a bug in the UEFI implementation itself, which is not related to Secure Boot directly. It can affect Secure Boot and maybe turn it off, but that is not the direction I was looking for in this "bug" report. Of course, we are looking into several other aspects to circumvent Secure Boot, and this presentation is indeed relevant. However, GRUB not verifying the kernel is something what should be done later on or display the user with a warning (as discussed previously).

Indeed, at this moment GRUB is explicitly trying to verify kernels, but will also silently fallback to ignoring failed verification so that users can still boot their systems. Note that this is the case for a few reasons, among which that ensuring a full trust chain is hard when one also has to load modules that are locally built (we can't ship our signing key on all systems, it would defeat the purpose).

Fixing this is the target of spec foundations-x-installing-unsigned-secureboot.

Some basic considerations:
 - fixing grub to not silently ignore validation results
 - provide some way for users to disable validation in shim (MokSB) when they need to use custom drivers or kernels
 - ship mokutil by default so a tool is there to toggle validation

And as later steps:
 - replace disabling validation (MokSB) with allowing users to enroll their own keys from the installer, where we can helpfully walk them through the key generation and enrollment.

We're probably only looking at toggling validation for 16.04.

The net effect of properly relying on shim's validation of the signatures from grub will be to automatically show a "Booting in insecure mode" message when validation is disabled, but SecureBoot is enabled. If SecureBoot is disabled, validation would succeed anyway in both the signed kernels and unsigned kernels.

For more information, I'd refer you to the blueprint or to the source code for shim (https://github.com/rhinstaller/shim), or contact me (cyphermox) on IRC in #ubuntu-installer.

Changed in grub2-signed (Ubuntu):
status: Triaged → In Progress

Re-assigning to grub; this "simply" needs modifying one of the linuxefi patches to not fallback to linux when linuxefi fails; but depends on having the installer, mokutil and some minimal infrastructure (new shim keys) in place to handle making this easy for users to "disable" first if they use DKMS modules.

affects: grub2-signed (Ubuntu) → grub2 (Ubuntu)
Changed in grub2 (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Tim Hitchins (timtjtim) on 2016-01-28
description: updated
kay (kay-diam) wrote :

Will you manage to fix it before xenial release?

Alexander (sality) wrote :

Same problem. Nvidia-prime doesn't works

tags: added: xenial

Resetting to Triaged; we're fixing this, but I can't realistically say that I'm actively working on it at the moment. It involves moving to a new signing key before we can stop grub from falling back to 'linux' when 'linuxefi' validation fails.

This has nothing to do with nvidia-prime or loading whatever drivers -- drivers still load normally, this changes nothing at all but the fact that on a failure to validate the kernel image, grub will still load the badly-signed kernel rather than reporting an error and kicking the user back to the GRUB menu.

Changed in grub2 (Ubuntu):
status: In Progress → Triaged
importance: Wishlist → High
QkiZ (qkiz) wrote :

Ubuntu 16.10. Secure boot is working but I'm able to load unsigned kernel.

QkiZ (qkiz) wrote :

After reboot and load signed kernel I can load unsigned modules.

QkiZ, this is not the bug for that. Please file your own bug, and include the details as to how you did the installation, and including what /proc/sys/kernel/secure_boot and /proc/sys/kernel/moksbstate_disabled report. There can be various reasons for unsigned binaries to be loaded despite Secure Boot being marked as enabled in the firmware.

Thorsten Leemhuis (thleemhuis) wrote :

> there can be various reasons for unsigned binaries to be loaded
> despite Secure Boot being marked as enabled in the firmware.

@cyphermox: I'd be curious to know what these "various reasons" are. Obviously one is: Secure Boot enforcement was disabled via MokManager in Shim. But what other reasons are there? If you have a minute could you please mentione them? tia!

@Thorsten,

Secure Boot enforcement being disabled is indeed one. Being in Setup Mode is another. Updates may have been missing on the system too (since things only happen provided that you have installed the relevant update that ships the change). Also, as per this bug, one could also be explicitly asking grub to load via linuxefi an unsigned kernel binary. The point is that until you are sure what this particular issue is, it is better to open a new bug. This is done to avoid muddying the waters with unrelated issues, and help us avoid "forgetting" to fix something because it was one slightly different issue on an unrelated bug.

I'm updating the description for this bug and opening a grub2-signed task (and the relevant release tasks). We're at the point where the grub2 fallback code needs to be addressed.

description: updated
Changed in grub2-signed (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Launchpad Janitor (janitor) wrote :

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

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

  * debian/build-efi-images: provide a new grub EFI image which enforces that
    loaded kernels are signed for Secure Boot: build gsb$arch.efi; which is
    the same as grub$arch.efi minus the 'linux' module. Without fallback to
    'linux' for unsigned loading, this makes it effectively enforce having a
    signed kernel. (LP: #1401532)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 30 Mar 2017 17:45:23 -0400

Changed in grub2 (Ubuntu Zesty):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2-signed - 1.80

---------------
grub2-signed (1.80) zesty; urgency=medium

  * Rebuild against grub2 2.02~beta3-4ubuntu2. (LP: #1401532)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 04 Apr 2017 10:28:34 -0400

Changed in grub2-signed (Ubuntu Zesty):
status: Triaged → Fix Released
John S. Gruber (jsjgruber) wrote :

I'm not seeing gsbx64.efi in grub2-signed. Should I?

If not, in what package is it distributed?

It's not shipped in any package right now, that wasn't the point for the time being (and this is why I'm setting things back to Triaged).

The gsbx64.efi.signed file here:
http://archive.ubuntu.com/ubuntu/dists/zesty/main/uefi/grub2-amd64/current/
... is the file you want; but for now there is no process that consumes that file to install it, even if it was provided in grub2-signed.

This is *not* a final product and *does* need additional changes to be used as such: any grub configuration will need to replace any 'linux' and 'initrd' calls with 'linuxefi' and 'initrdefi'.

This is just a temporary workaround to provide a way to enforce Secure Boot in the cases where this is needed.

Changed in grub2 (Ubuntu Zesty):
status: Fix Released → Triaged
Changed in grub2-signed (Ubuntu Zesty):
status: Fix Released → Triaged
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in grub2 (Ubuntu Trusty):
status: New → Confirmed
Changed in grub2 (Ubuntu Xenial):
status: New → Confirmed
Changed in grub2 (Ubuntu Yakkety):
status: New → Confirmed
Changed in grub2-signed (Ubuntu Trusty):
status: New → Confirmed
Changed in grub2-signed (Ubuntu Xenial):
status: New → Confirmed
Changed in grub2-signed (Ubuntu Yakkety):
status: New → Confirmed
Launchpad Janitor (janitor) wrote :
Download full text (4.5 KiB)

This bug was fixed in the package grub2 - 2.02-2ubuntu1

---------------
grub2 (2.02-2ubuntu1) bionic; urgency=medium

  * Merge with Debian; remaining changes:
    - debian/patches/support_initrd-less_boot.patch: Added knobs to allow
      non-initrd boot config. (LP: #1640878)
    - Disable os-prober for ppc64el on the PowerNV platform, to reduce the
      number of entries/clutter from other OSes in Petitboot (LP: #1447500)
    - debian/build-efi-images: provide a new grub EFI image which enforces that
      loaded kernels are signed for Secure Boot: build gsb$arch.efi; which is
      the same as grub$arch.efi minus the 'linux' module. Without fallback to
      'linux' for unsigned loading, this makes it effectively enforce having a
      signed kernel. (LP: #1401532)
    - debian/patches/install_signed.patch, grub-install-extra-removable.patch:
      - Make sure if we install shim; it should also be exported as the default
        bootloader to install later to a removable path, if we do.
      - Rework grub-install-extra-removable.patch to reverse its logic: in the
        default case, install the bootloader to /EFI/BOOT, unless we're trying
        to install on a removable device, or explicitly telling grub *not* to
        do it.
      - Move installing fb$arch.efi to --no-extra-removable; as we don't want
        fallback to be installed unless we're also installing to /EFI/BOOT.
        (LP: #1684341)
      - Make sure postinst and templates know about the replacement of
        --force-extra-removable with --no-extra-removable.
  * Sync Secure Boot support patches with the upstream patch set from
    rhboot/grub2:master-sb. Renamed some patches and updated descriptions for
    the whole thing to make more sense, too:
    - dropped debian/patches/linuxefi_require_shim.patch
    - renamed: debian/patches/no_insmod_on_sb.patch ->
      debian/patches/linuxefi_no_insmod_on_sb.patch
    - debian/patches/linuxefi.patch
    - debian/patches/linuxefi_debug.patch
    - debian/patches/linuxefi_non_sb_fallback.patch
    - debian/patches/linuxefi_add_sb_to_efi_chainload.patch
    - debian/patches/linuxefi_cleanup_errors_in_loader.patch
    - debian/patches/linuxefi_fix_efi_validation_race.patch
    - debian/patches/linuxefi_handle_multiarch_boot.patch
    - debian/patches/linuxefi_honor_sb_mode.patch
    - debian/patches/linuxefi_move_fdt_helper.patch
    - debian/patches/linuxefi_load_arm_with_sb.patch
    - debian/patches/linuxefi_minor_cleanups.patch
    - debian/patches/linuxefi_re-enable_linux_cmd.patch
    - debian/patches/linuxefi_rework_linux16_cmd.patch
    - debian/patches/linuxefi_rework_linux_cmd.patch
    - debian/patches/linuxefi_rework_non-sb_efi_chainload.patch
    - debian/patches/linuxefi_rework_pe_loading.patch
    - debian/patches/linuxefi_use_dev_chainloader_target.patch
  * debian/patches/dont-fail-efi-warnings.patch: handle linuxefi patches and
    the casting they do on some architectures: we don't want to fail build
    because of some of the warnings that can show up since we otherwise build
    with -Werror.

grub2 (2.02-3) UNRELEASED; urgency=medium

  * Use current location for upstream signing key
    (debian/ups...

Read more...

Changed in grub2 (Ubuntu):
status: Triaged → Fix Released
shivu (shivupatil) wrote :

HI,

Is this issue fixed?
Which ubuntu version includes this package?
Currently I am using ubuntu 18 but still I am facing the same issue. It loads unisgned kernel.

This probably should not have been closed as Fix Released quite yet. A gsbx64.efi binary was being built, which allowed enforcement.

Now, the proper fix to never allow unsigned / invalidly signed kernels has landed in Cosmic; so proceeding with the SRUs.

no longer affects: grub2 (Ubuntu Zesty)
no longer affects: grub2 (Ubuntu Yakkety)
no longer affects: grub2-signed (Ubuntu Yakkety)
no longer affects: grub2-signed (Ubuntu Zesty)
Changed in grub2 (Ubuntu Bionic):
status: New → In Progress
Changed in grub2-signed (Ubuntu Bionic):
status: New → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in grub2 (Ubuntu Bionic):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in grub2 (Ubuntu Xenial):
status: Confirmed → Triaged
Changed in grub2 (Ubuntu Trusty):
status: Confirmed → Triaged
Changed in grub2-signed (Ubuntu Trusty):
status: Confirmed → Triaged
Changed in grub2-signed (Ubuntu):
status: Triaged → Fix Released
Changed in grub2-signed (Ubuntu Xenial):
status: Confirmed → Triaged
Changed in grub2-signed (Ubuntu Bionic):
importance: Undecided → High
Changed in grub2-signed (Ubuntu Xenial):
importance: Undecided → High
Changed in grub2-signed (Ubuntu Trusty):
importance: Undecided → High
Changed in grub2 (Ubuntu Bionic):
importance: Undecided → High
Changed in grub2 (Ubuntu Xenial):
importance: Undecided → High
Changed in grub2 (Ubuntu Trusty):
importance: Undecided → High

An upload of grub2 to bionic-proposed has been rejected from the upload queue for the following reason: "as discussed on IRC we aren't ready to flip the switch yet on kernel sig enforcement".

Steve Langasek (vorlon) wrote :

An upload of grub2-signed to bionic-proposed has been rejected from the upload queue for the following reason: "as discussed on IRC we aren't ready to flip the switch yet on kernel sig enforcement".

Paddy Landau (paddy-landau) wrote :

I believe that bug #1565950 is related (but not a duplicate).

Hello Wouter, or anyone else affected,

Accepted grub2 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.11 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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in grub2 (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-bionic
Steve Langasek (vorlon) wrote :

Hello Wouter, or anyone else affected,

Accepted grub2-signed into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.93.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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in grub2-signed (Ubuntu Bionic):
status: In Progress → Fix Committed
Steve Langasek (vorlon) wrote :

Hello Wouter, or anyone else affected,

Accepted grub2 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Steve Langasek (vorlon) wrote :

Hello Wouter, or anyone else affected,

Accepted grub2-signed into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.93.13 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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Verification-done for bionic using grub2/2.02-2ubuntu8.12, grub2-signed/1.93.13:

I have checked loading both signed and unsigned kernels. As expected, an official, correctly signed kernel from the bionic archive is loaded correctly, and a copy of the same kernel with the key removed ('sbattach --remove <kernel>') fails to load with "invalid signature" message.

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

This bug was fixed in the package grub2 - 2.02-2ubuntu8.12

---------------
grub2 (2.02-2ubuntu8.12) bionic; urgency=medium

  * debian/grub-check-signatures: make sure grub-check-signatures conserves
    its execute bit.

grub2 (2.02-2ubuntu8.11) bionic; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * debian/grub-check-signatures: properly account for DB showing as empty on
    some broken firmwares: Guard against mokutil --export --db failing, and do
    a better job at finding the DER certs for conversion to PEM format.
    (LP: #1814575)
  * debian/patches/linuxefi_disable_sb_fallback.patch: Disallow unsigned
    kernels if UEFI Secure Boot is enabled. If UEFI Secure Boot is enabled
    and kernel signature verification fails, do not boot the kernel. Patch
    from Linn Crosetto. (LP: #1401532)

  [ Steve Langasek ]
  * debian/patches/quick-boot-lvm.patch: checking the return value of
    'lsefi' when the command doesn't exist does not do what's expected, so
    instead check the value of $grub_platform which is simpler anyway.
    LP: #1814403.

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 07 Feb 2019 18:20:04 -0500

Changed in grub2 (Ubuntu Bionic):
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.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2-signed - 1.93.13

---------------
grub2-signed (1.93.13) bionic; urgency=medium

  * Rebuild against grub2 2.02-2ubuntu8.12.

grub2-signed (1.93.12) bionic; urgency=medium

  * Rebuild against grub2 2.02-2ubuntu8.11.
    (LP: #1401532) (LP: #1814403) (LP: #1814575)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 07 Feb 2019 19:28:09 -0500

Changed in grub2-signed (Ubuntu Bionic):
status: Fix Committed → Fix Released
Changed in grub2 (Ubuntu Trusty):
status: Triaged → In Progress
Changed in grub2-signed (Ubuntu Trusty):
status: Triaged → In Progress
Changed in grub2 (Ubuntu Trusty):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in grub2-signed (Ubuntu Trusty):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in grub2-signed (Ubuntu Xenial):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in grub2 (Ubuntu Xenial):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
status: Triaged → In Progress
Changed in grub2-signed (Ubuntu Xenial):
status: Triaged → In Progress

Hello Wouter, or anyone else affected,

Accepted grub2 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-9ubuntu1.17 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-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in grub2 (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-trusty
Steve Langasek (vorlon) wrote :

Hello Wouter, or anyone else affected,

Accepted grub2-signed into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.34.19 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-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in grub2-signed (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-done-trusty
removed: verification-needed-trusty

Verification-failed on trusty:

ii grub-common 2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader (common files)
ii grub-efi-amd64 2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii grub-efi-amd64-bin 2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 binaries)
ii grub-efi-amd64-signed 1.34.19+2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version, signed)
ii grub-legacy-ec2 0.7.5-0ubuntu1.23 all Handles update-grub for ec2 instances
ii grub-pc-bin 2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader, version 2 (PC/BIOS binaries)
ii grub2-common 2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader (common files for version 2)

Kernel signatures are correctly enforced, but a postinst check is missing in grub2-signed to check signatures before applying the next update (missing in grub2-signed 1.34.19)

tags: added: verification-failed-trusty
removed: verification-done-trusty
Steve Langasek (vorlon) wrote :

Hello Wouter, or anyone else affected,

Accepted grub2-signed into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.34.20 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-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

tags: added: verification-needed-trusty
removed: verification-failed-trusty

Verification-done on trusty:

ubuntu@dashing-moccasin:~$ apt-cache policy grub-efi-amd64-signed
grub-efi-amd64-signed:
  Installed: 1.34.20+2.02~beta2-9ubuntu1.17
  Candidate: 1.34.20+2.02~beta2-9ubuntu1.17
  Package pin: 1.34.20+2.02~beta2-9ubuntu1.17
  Version table:
 *** 1.34.20+2.02~beta2-9ubuntu1.17 500
         -1 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     1.34.18+2.02~beta2-9ubuntu1.16 500
        500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
     1.34.7+2.02~beta2-9ubuntu1.6 500
        500 http://archive.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
     1.34+2.02~beta2-9 500
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
ubuntu@dashing-moccasin:~$ apt-cache policy grub-efi-amd64
grub-efi-amd64:
  Installed: 2.02~beta2-9ubuntu1.17
  Candidate: 2.02~beta2-9ubuntu1.17
  Package pin: 2.02~beta2-9ubuntu1.17
  Version table:
 *** 2.02~beta2-9ubuntu1.17 500
         -1 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.02~beta2-9ubuntu1.16 500
        500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
     2.02~beta2-9ubuntu1.6 500
        500 http://archive.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
     2.02~beta2-9 500
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

Verified that now the kernel signature is correctly enforced by grub, and if no kernel is signed / signed by a trusted key, the upgrade will correctly be failed to avoid leaving the system unbootable.

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

This bug was fixed in the package grub2 - 2.02~beta2-9ubuntu1.17

---------------
grub2 (2.02~beta2-9ubuntu1.17) trusty; urgency=medium

  * debian/grub-check-signatures: check kernel signatures against keys known
    in firmware, in case a kernel is signed but not using a key that will pass
    validation, such as when using kernels coming from a PPA. (LP: #1789918)
  * debian/patches/linuxefi_disable_sb_fallback.patch: Disallow unsigned
    kernels if UEFI Secure Boot is enabled. If UEFI Secure Boot is enabled
    and kernel signature verification fails, do not boot the kernel. Patch
    from Linn Crosetto. (LP: #1401532)

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 22 Mar 2019 11:36:54 -0400

Changed in grub2 (Ubuntu Trusty):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2-signed - 1.34.20

---------------
grub2-signed (1.34.20) trusty; urgency=medium

  * Run grub-check-signatures before running grub-install, to block upgrade if
    no signed kernels are installed. (LP: #1789918)

grub2-signed (1.34.19) trusty; urgency=medium

  * Rebuild against grub-efi-amd64 2.02~beta2-9ubuntu1.17
    (LP: #1401532) (LP: #1789918)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 01 Apr 2019 12:03:07 -0400

Changed in grub2-signed (Ubuntu Trusty):
status: Fix Committed → Fix Released

For Xenial we're currently blocked on some kernel work that needs to happen before we enable enforcement for that release in grub2.

Steve Langasek (vorlon) wrote :

The last comment from Mathieu is still the current status. We have not toggled signature enforcement for xenial yet because we have a Canonical-supported kernel, linux-fips, which is published for xenial and there is not yet a version of this kernel which is both FIPS-certified and EFI signed.

The process of certifying a new kernel takes some time and depends on external entities.

We are currently still in a holding pattern waiting for that external certification to be completed.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers