arm64: shim crashes in SecureBoot mode w/ some firmware

Bug #1811722 reported by dann frazier
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
shim (Ubuntu)
Fix Released
Undecided
Unassigned
shim-signed (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

On some firmware, attempting SecureBoot on arm64 will result in a crash. This is reproducible with a build of latest upstream EDK2 for the ArmVirtQemu target, but not with the older version we have packaged (edk2 0~20181115.85588389-2ubuntu1). The reason appears to be that our older version of edk2 had the firmware flash mapped at 0x0, which allowed NULL pointer dereferences to silently succeed. Latest upstream has changed that, so now such accesses result in a Synchronous Exception.

Even though we can boot in SecureBoot mode successfully with the old firmware, I've found that doing so results in a corrupted firmware image, making subsequent boots fail. It maybe that the memory access that leads to the Synchronous Exception on newer firmware is a write to the firmware region that is causing the corruption, and therefore the same underlying root cause.

Note that I can also reproduce this with latest upstream GRUB. I looked for possible fixes for this in shim upstream, in case it is a problem with how shim invokes GRUB - or an issue with the Protocols shim registers. The only change I see that might be relevant that we don't already have is "6df7a8f Fix for "Section 0 has negative size" error when loading fbaa64.efi", but I could still reproduce after applying that.

Revision history for this message
dann frazier (dannf) wrote :
description: updated
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Doesn't look like a grub bug anymore. We can set back to New if necessary.

Changed in grub2-signed (Ubuntu):
status: New → Invalid
Revision history for this message
dann frazier (dannf) wrote :

There are actually 2 separate bugs. The first is a bug in gnu-efi, triggered by this call in shim's errlog.c:

size = SPrint(NULL, 0, L"%a:%d %a() ", file, line, func);

According to the gnu-efi source, "A size of 0 means there is no limit", but SPrint does not check for NULL as the first parameter, and happily dereferences it anyway.

The other issue I've reported in LP: #1811901.

Changed in gnu-efi (Ubuntu):
status: New → Confirmed
Changed in shim-signed (Ubuntu):
status: New → Confirmed
dann frazier (dannf)
summary: - arm64: GRUB crashes in SecureBoot mode w/ some firmware
+ arm64: shim crashes in SecureBoot mode w/ some firmware
Revision history for this message
dann frazier (dannf) wrote :

I've proposed a fix upstream:
  https://github.com/rhboot/shim/pull/173

dann frazier (dannf)
Changed in shim (Ubuntu):
status: New → In Progress
dann frazier (dannf)
Changed in gnu-efi (Ubuntu):
status: Confirmed → Invalid
Changed in shim (Ubuntu):
status: In Progress → Fix Committed
Changed in shim-signed (Ubuntu):
status: Confirmed → Fix Committed
Mathew Hodson (mhodson)
no longer affects: gnu-efi (Ubuntu)
no longer affects: grub2-signed (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package shim - 15+1552672080.a4a1fbe-0ubuntu1

---------------
shim (15+1552672080.a4a1fbe-0ubuntu1) eoan; urgency=medium

  * New upstream snapshot 15+1552672080.a4a1fbe.
  * debian/patches/VLogError-Avoid-NULL-pointer-dereferences-in-V-Sprin.patch,
    debian/patches/fixup_git.patch: drop patches included in upstream.
  * debian/patches/MokManager-avoid-unaligned.patch: Fix compilation with GCC9:
    avoid -Werror=address-of-packed-member errors in MokManager.
  * debian/patches/tpm-correctness-1.patch,
    debian/patches/tpm-correctness-2.patch: fix issues in TPM calls to ensure
    the measurements are consistent with what is entered in the TPM event log.
  * debian/patches/tpm-correctness-3.patch: Don't log duplicate identical
    TPM events.
  * debian/patches/MokManager-hidpi-support.patch: Do a little bit more to
    try to get a more usable screen resolution for MokManager when running on
    HiDPI screens; by trying to detect such cases and switching to mode 0.
  * debian/rules: update COMMIT_ID explicitly for this new snapshot.

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 11 Oct 2019 16:32:32 -0400

Changed in shim (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
xinliang (xin3liang) wrote :

I encounter a Synchronous Exception crash when booting shim with qemu-system-aarch64 on Focal. But on an real aarch64 server this doesn't happen.
Not sure if it is the same issue.

software:
qemu-efi-aarch64/focal,now 0~20191122.bd85bf54-2ubuntu3 all [installed,automatic]
  UEFI firmware for 64-bit ARM virtual machines
shim/focal,now 15+1533136590.3beb971-0ubuntu1 arm64 [installed]
  boot loader to chain-load signed boot loaders under Secure Boot

shim-signed/focal,now 1.40.3+15+1533136590.3beb971-0ubuntu1 arm64 [installed]
  Secure Boot chain-loading bootloader (Microsoft-signed binary)

log show as bellow:
$ virsh console node-0
Connected to domain node-0
Escape character is ^]

>>Start PXE over IPv4.
  Station IP address is 10.0.0.31

  Server IP address is 10.30.96.1
  NBP filename is bootaa64.efi
  NBP filesize is 910544 Bytes
 Downloading NBP file...

  NBP file downloaded successfully.
BdsDxe: loading Boot0002 "UEFI PXEv4 (MAC:525400C65BC2)" from PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(525400C65BC2,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)
BdsDxe: starting Boot0002 "UEFI PXEv4 (MAC:525400C65BC2)" from PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(525400C65BC2,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)

Synchronous Exception at 0x00000000F83BBDEC

Synchronous Exception at 0x00000000F83BBDEC

Revision history for this message
Julian Andres Klode (juliank) wrote :

Please open a new bug.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.