Public bug reported:
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.
** Affects: grub2-signed (Ubuntu)
Importance: Undecided
Status: New
** Affects: shim-signed (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "Console log w/ debug firmware"
https://bugs.launchpad.net/bugs/1811722/+attachment/5229053/+files/console.log
** Also affects: shim-signed (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
On some firmware, attempting SecureBoot on arm64 will result in a crash.
- This is reproducible with a build 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.
+ 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.
- With SecureBoot disabled, we can boot successfully with the old
- firmware. However, I've found that this results in a corrupted firmware
+ 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1811722
Title:
arm64: GRUB crashes in SecureBoot mode w/ some firmware
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1811722/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
