arm64 Secure Boot fails w/ "error: cannot load image."

Bug #1862279 reported by dann frazier on 2020-02-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
grub2-signed (Ubuntu)
shim (Ubuntu)

Bug Description

I tested out the new shim-signed (1.41+15+1552672080.a4a1fbe-0ubuntu1) on arm64 today. Unfortunately, I was unable to boot a kernel. I tried manually running commands in the GRUB shell to try and get more info, and here's the error I get:

grub> insmod gzio
grub> linux (hd0,gpt1)/boot/vmlinuz-5.4.0-13-generic
grub> boot
error: cannot load image.

This is better then it was previously - shim used to crash before starting GRUB (bug 1811901 and bug 1811722). But obviously there are still issues somewhere. Prior to this shim binary being signed, I believe I had tested the unsigned binary in a VM using a custom signing certificate. I think I still have that VM around, so I maybe able to use it for comparison.

= My setup =
I tried to make this test simulate a real setup as much as possible. Here's roughly what I did:

Installed an arm64 server w/ bionic
# need a new QEMU for EnrollDefaultKeys.efi
sudo apt-add-repository cloud-archive:train
sudo apt update
sudo apt install uvtool
sudo gpasswd -a ubuntu libvirt
# log out/back in
# no focal images yet
uvt-simplestreams-libvirt -v sync release=eoan
uvt-kvm create focal arch=arm64 release=eoan
uvt-kvm wait focal
uvt-kvm ssh focal
guest> sudo sed -i 's/eoan/focal/' /etc/apt/sources.list
guest> # Also enabled focal-proposed to get latest shim-signed
guest> sudo apt update
guest> sudo apt dist-upgrade
guest> sudo apt install shim-signed
guest> sudo grub-install
# On an x86 host, I built the latest edk2 package and copied out the AARCH64 build of
# EnrollDefaultKeys.efi. I scp'd this over to the focal guest, and put it in the EFI
# system partition
guest> sudo poweroff
virsh edit focal
# Add the following to inject the Pk/KEK keys:
# <qemu:commandline>
# <qemu:arg value='-smbios'/>
# <qemu:arg value='type=11,value=4e32566d-8e9e-4f52-81d3-5bb9715f9727:MIIDNjCCAh4CCQCUy69JzVan2DANBgkqhkiG9w0BAQsFADBdMS0wKwYDVQQDDCRVYnVudHUgT1ZNRiBTZWN1cmUgQm9vdCAoUEsvS0VLIGtleSkxLDAqBgkqhkiG9w0BCQEWHXVidW50dS1kZXZlbEBsaXN0cy51YnVudHUuY29tMB4XDTE4MDYyMDIxNDg0NloXDTI4MDYxNzIxNDg0NlowXTEtMCsGA1UEAwwkVWJ1bnR1IE9WTUYgU2VjdXJlIEJvb3QgKFBLL0tFSyBrZXkpMSwwKgYJKoZIhvcNAQkBFh11YnVudHUtZGV2ZWxAbGlzdHMudWJ1bnR1LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMuwK+l3nl5x6ebrHYVShs/7jPAKeTTMu4MQlTbNoOZvVQhOcedjkBNaPPdd63TBxYFAnJhUBLl9hW/GB5Fn9itT0yh5G64XCBafy3rJLF8L99VDUYEuvB+a3boYATCToVnODb8h0ImORBF8sgKZm65CJlgQ93YGZbjLePnuawhU2EVH2HFyLZEWjd3JPxstlzGj+JiwvETdFX/fHbnrW+fLCLEnLLZ/YPo6We0mtVTEqHWm6G5WUIbpzPzOOGpiCKHdI+VFsX7w1TBdMhCqnxcpLn7NRXEEgw+OQ5gnOLR9kTKI+MRkux9pDGZ5v9VMcPZi2iZTHRd9briIGOL/fo0CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAGLAtUs7fnf5oKU7E7+woUrHP03WXAwhTNI9eTs7YLPgwC2qGAGkzdUZUbzc4zS4SaItITlYYeWfZ9PvPhPGyIZOeuBMoUeBknsC2daRVX11aAcgOnQhxMD0WjSRG5nQ5rXRZ/NwYvctJR81l41kDToNqjBIjJ3FThzz8hHyMv/DCh3ch/X2Hj7ib+1IPfoHFk+mD/6e+y46wHWS5u0Bol9w4VBMwa3FYniFgKrAmnoiuo2br5fBbgH/7326lJ7Qb/H4mBLKz/c3iw4PF+KQxspc04tJdvQ+pDEtTUiXVE0zcBip2EJgPVK0szO5H6gtXbfyoTqDr1DKaD4x9JD3yKQ=='/>
# </qemu:commandline>
virsh start focal; virsh console focal
# Interrupt focal boot, drop to an EFI shell, then ran the following
# which will load the PK/Kek1 and Microsoft keys and enable SecureBoot
Shell> fs0:
FS0:\> EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
FS0:\> reset -s
# Then, finally, try and boot in SB mode:
virsh start focal; virsh console focal

Dimitri John Ledkov (xnox) wrote :

le sigh

dann frazier (dannf) wrote :

I dug up my arm64/disco VM that I had hacked up to test this shim build before MS had signed it:

ubuntu@disco:~$ sudo mokutil --sb-state
SecureBoot enabled

So what's the relevant difference between this working config and the broken one?

Looks like I had set it up following:

That is, I had created and installed unique PK, KEK & db keys:
ubuntu@disco:~$ sudo mokutil --pk | grep Issuer
        Issuer: CN=my Platform Key
ubuntu@disco:~$ sudo mokutil --kek | grep Issuer
        Issuer: CN=my Key Exchange Key
ubuntu@disco:~$ sudo mokutil --db | grep Issuer
        Issuer: CN=my Signature Database key
ubuntu@disco:~$ sudo mokutil --dbx | grep Issuer

I had signed shim w/ my custom db key:
ubuntu@disco:~$ sudo sbverify --cert db.crt /boot/efi/EFI/ubuntu/shimaa64.efi
warning: data remaining[836920 vs 900344]: gaps between PE/COFF sections?
Signature verification OK

And apparently GRUB as well:
ubuntu@disco:~$ sudo sbverify --cert db.crt /boot/efi/EFI/ubuntu/grubaa64.efi
Signature verification OK

While the kernel is an unmodified signed Canonical image.

Some package versions:
ubuntu@disco:~$ dpkg -l | grep -e shim
ii shim 15+1552672080.a4a1fbe-0ubuntu1 arm64 boot loader to chain-load signed boot loaders under Secure Boot
ii shim-signed 1.40~uefi1+dannf.1+15+1552672080.a4a1fbe-0ubuntu1 arm64 Secure Boot chain-loading bootloader (Microsoft-signed binary)
ubuntu@disco:~$ dpkg -l | grep grub
ii grub-common 2.02+dfsg1-12ubuntu2.1 arm64 GRand Unified Bootloader (common files)
ii grub-efi-arm64 2.02+dfsg1-12ubuntu2.1 arm64 GRand Unified Bootloader, version 2 (ARM64 UEFI version)
ii grub-efi-arm64-bin 2.02+dfsg1-12ubuntu2.1 arm64 GRand Unified Bootloader, version 2 (ARM64 UEFI modules)
ii grub-efi-arm64-signed 1.115+2.02+dfsg1-12ubuntu2 arm64 GRand Unified Bootloader, version 2 (EFI-ARM64 version, signed)
ii grub2-common 2.02+dfsg1-12ubuntu2.1 arm64 GRand Unified Bootloader (common files for version 2)
ubuntu@disco:~$ dpkg -l | grep linux-image
ii linux-image-5.0.0-36-generic 5.0.0-36.39 arm64 Signed kernel image generic
ii linux-image-5.0.0-37-generic 5.0.0-37.40 arm64 Signed kernel image generic
ii linux-image-virtual arm64 Virtual Linux kernel image

And from the host:
ii qemu-efi-aarch64 0~20191122.bd85bf54-1 all UEFI firmware for 64-bit ARM virtual machines

dann frazier (dannf) wrote :

It does not appear to be an issue with the signed kernel - the same one that fails to build in my focal/MS-signed VM does boot when installed in the disco/self-signed VM.

dann frazier (dannf) wrote :

The issue seems to be related to GRUB. If I upgrade my working-in-SB-disco VM to focal's grub-efi-arm64-signed, it now fails. If I downgrade my *not*-working-in-SB-focal VM to disco's grub-efi-arm64-signed, it now boots in SB mode.

dann frazier (dannf) wrote :

Upstream GRUB 2.02 also fails - so there's likely something in the disco patchset that is required.

Julian Andres Klode (juliank) wrote :

Does it work with new grub and old shim, though? As we think new shim is somewhat buggy, it also fails to load fwupd on x86.

dann frazier (dannf) wrote :

@juliank: The shim build is the same in both cases. The only difference is that one is signed by MS, the other self-signed. I did notice that key enrollment didn't work in my guest, which maybe a failure to execute mma64.efi, and therefore maybe related to bug 1864223.

My hypothesis is that the SB support for arm64 is not upstream, and there was a regression introduced when rebasing those patches on GRUB 2.04.

Steve Langasek (vorlon) wrote :

also note that the previous version of shim did not work on arm64 AT ALL. This version of shim we just got signed is the first one with arm64 support.

dann frazier (dannf) wrote :

I've got a hacked together focal-based GRUB I created by replacing some patches w/ updated versions from the rhboot repository. It still need quite a bit of cleanup though.

dann frazier (dannf) wrote :

I've compared the list of patches squashed into the ubuntu-linuxefi.patch we have in focal with the current set of patches in the fedora-32 branch of, which is the upstream for our SB patches AIUI. There has been some rework of the linuxefi command since the version we last picked up - but it does appear to have equivalent functionality and fixes this regression. My proposal would be to do a "replace and rebase" of those patches to fix this bug and, presumably simplify focal maintenance somewhat by being more in sync with our upstream.

dann frazier (dannf) on 2020-03-12
Changed in shim (Ubuntu):
status: New → Invalid
dann frazier (dannf) wrote :

I've nearly completed the rebase - here's what I have so far:

However, it fails to build on armhf now due to the changes in how the fdt module is built:
(That's a log from a slightly older version of my rebase, but the armhf failure is the same)

I need to find some doc or human that can help me understand the wizardry of Makefile.core.def to figure out how to fix that.

tags: added: id-5e67b5f44d0dff7b9bbf1d1a
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers