grub or kernel update broke Secure Boot by putting grubx64.efi instead of shimx64.efi in EFI boot order

Bug #1528345 reported by L. David Baron on 2015-12-21
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Critical
Unassigned
grub2 (Ubuntu)
Critical
Unassigned
Nominated for Wily by Alberto Salvia Novella
linux (Ubuntu)
Critical
Unassigned
Nominated for Wily by Alberto Salvia Novella

Bug Description

I've been running Ubuntu on a Lenovo ThinkPad X240. I initially installed 14.10 when I got the machine in January. I then upgraded to 15.04, and on Monday evening (late December 14) I upgraded to 15.10. I rebooted once right after the update to make sure some postfix and opendkim configuration changes I made worked correctly after rebooting.

Then between Monday evening and Friday evening (December 19) there were a bunch of system updates that I installed. On Friday evening I decided to reboot to boot into the updated kernel. (There were also grub updates in that interval.)

When I rebooted, the laptop said:

Secure Boot
Image failed to verify with *ACCESS DENIED*
Press any key to continue.

See the image (posted by somebody else) of this error in http://askubuntu.com/questions/710146/how-to-fix-secure-boot-error-image-failed-to-verify-with-access-denied-on-st

I had to disable secure boot to make the system boot.

Based on the discussion in http://askubuntu.com/questions/710146/how-to-fix-secure-boot-error-image-failed-to-verify-with-access-denied-on-st it appears that the problem is that the updates caused it to try to boot directly to grub (File(\EFI‌​\ubuntu\grubx64.efi)) rather than via the shim (File(\EFI‌​\ubuntu\shimx64.efi)). I don't know for sure what sequence of events caused that, nor did I verify for certain that it was booting via the shim before. However, I know that this reboot on Friday was the first time I had a secure boot failure since installing Ubuntu on the laptop (and using only Ubuntu; no other OSes involved) in January.

I'll attach a list of the system updates that were applied in the interval between the successful boot and the failed one from /var/log/dpkg.log . Note that the log is in UTC but my description above ("evening", etc., is in UTC-8, so the evening of December 14 is actually around 07:00 UTC on December 15). Note that this log contains a grub update, two kernel updates, and the removal of the first of those kernel updates via apt-get autoremove.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: grub-common 2.02~beta2-29ubuntu0.2
ProcVersionSignature: Ubuntu 4.2.0-22.27-generic 4.2.6
Uname: Linux 4.2.0-22-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Dec 21 15:39:21 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-01-25 (330 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
SourcePackage: grub2
UpgradeStatus: Upgraded to wily on 2015-12-15 (6 days ago)

L. David Baron (dbaron) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed
Changed in grub2 (Ubuntu):
importance: Undecided → Critical
Changed in hundredpapercuts:
status: New → Confirmed
importance: Undecided → Critical
Changed in linux (Ubuntu):
importance: Undecided → Critical
status: New → Triaged
Changed in grub2 (Ubuntu):
status: Confirmed → Triaged
planet (planet1) on 2016-01-05
tags: added: kernel-fs
tags: added: regression-update
Steve Langasek (vorlon) wrote :

This appears to have been caused by the publication of a grub2 security update on 12/15 without the corresponding grub2-signed package being published at the same time.

We have had similar issues in the past with publication of grub2 and grub2-signed to the -updates pockets; the proposed solution there won't help for the security pocket, however, since those publications don't go via -proposed.

Subscribing the security team for comment.

To fix your current problem, you should install the grub-efi-amd64-signed package.

Changed in linux (Ubuntu):
status: Triaged → Invalid
Seth Arnold (seth-arnold) wrote :

Will users that have only the -security pocket enabled run into this issue until we publish a corresponding grub2-signed package into the -security pocket? Can the packages in -updates in wily, vivid, and trusty be binarycopied into the -security pocket?

What steps need to be taken to publish future grub2 security updates?

Thanks

On Thu, Jan 07, 2016 at 03:59:30AM -0000, Seth Arnold wrote:
> Will users that have only the -security pocket enabled run into this
> issue until we publish a corresponding grub2-signed package into the
> -security pocket?

Yes.

> Can the packages in -updates in wily, vivid, and trusty be binarycopied
> into the -security pocket?

That doesn't help. The grub2 and grub2-signed packages must be in exact
version lockstep to avoid problems.

> What steps need to be taken to publish future grub2 security updates?

Upon unembargo, the grub2 package needs to be copied first from the security
ppa to -proposed, where the grub .efi binaries can be signed, and then
grub2-signed needs to be uploaded to -proposed, after which the packages can
be copied to -security.

Marc Deslauriers (mdeslaur) wrote :

Wouldn't the grub2 package simply be held back if the proper version required by grub2-signed isn't available?

Why did the grub2-signed binary package get uninstalled during the update?

2015-12-15 20:26:59 status installed grub-efi-amd64-signed:amd64 1.55+2.02~beta2-29
2015-12-15 20:27:00 remove grub-efi-amd64-signed:amd64 1.55+2.02~beta2-29 <none>

Steve Langasek (vorlon) wrote :

On Thu, Jan 07, 2016 at 07:14:48PM -0000, Marc Deslauriers wrote:
> Wouldn't the grub2 package simply be held back if the proper version
> required by grub2-signed isn't available?

Not in all cases.

> Why did the grub2-signed binary package get uninstalled during the
> update?

This is allowable when running 'apt-get dist-upgrade', which is presumably
how the affected users have been applying updates.

When using update-manager, we have more control to avoid accidental removal
of packages when applying updates. When a user explicitly invokes apt-get,
we don't have control over this.

Steve Langasek (vorlon) wrote :

On Thu, Dec 27, 2018 at 08:25:41PM -0000, bokateeka wrote:
> Try https://sourceforge.net/u/yannubuntu/

> Dual Boot repair disk

Please do nothing of the sort. This "repair disk" is developed with zero
coordination with the Ubuntu developers and the resulting changes to the
disk are unsupportable by us.

carmelo (c-carmelo) on 2019-01-28
Changed in grub2 (Ubuntu):
status: Triaged → Confirmed
Steve Langasek (vorlon) on 2019-01-28
Changed in grub2 (Ubuntu):
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers