[Bug 1862279] Re: arm64 Secure Boot fails w/ "error: cannot load image."

dann frazier dann.frazier at canonical.com
Tue Feb 25 20:30:28 UTC 2020


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

ubuntu at 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:
  https://wiki.archlinux.org/index.php/Secure_Boot

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

I had signed shim w/ my custom db key:
ubuntu at 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 at 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 at 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 at 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 at 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              5.0.0.37.39                                       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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to shim in Ubuntu.
https://bugs.launchpad.net/bugs/1862279

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

Status in shim package in Ubuntu:
  New

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

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



More information about the foundations-bugs mailing list