Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1042438: qemu-efi-aarch64: fails to boot aarch64 vm
51 views
Skip to first unread message
Simon John
Jul 28, 2023, 5:00:04 AM7/28/23
to
Package: qemu-efi-aarch64
Version: 2023.05-1
Severity: important
Source: edk2
Tried to report this using reportbug but it doesn't seem to have worked.
This may be bug #1025656 again, I can't really tell from the error message.
Essentially a pre-existing AlmaLinux 9.2 aarch64 VM will now no longer
boot when using qemu-efi-aarch64/qemu-efi-arm 2023.05-1 in Sid.
As soon as I start the vm i get the following error message:
"""
BdsDxe: loading Boot0004 "AlmaLinux" from
HD(1,GPT,045389FA-D6F1-4E82-9801-60BC98C37B6D,0x800,0x12C000)/\EFI\almalinux\shimaa64.efi
BdsDxe: starting Boot0004 "AlmaLinux" from
HD(1,GPT,045389FA-D6F1-4E82-9801-60BC98C37B6D,0x800,0x12C000)/\EFI\almalinux\shimaa64.efi
Synchronous Exception at 0x000000013BE2C89C
Synchronous Exception at 0x000000013BE2C89C
"""
Downgrading to qemu-efi-aarch64_2022.11-6_all.deb fixes the issue.
Scripts to create the VM are here:
https://github.com/sej7278/virt-installs/tree/master/alma9_arm
Regards.
--
Simon John
Version: 2023.05-1
Severity: important
Source: edk2
Tried to report this using reportbug but it doesn't seem to have worked.
This may be bug #1025656 again, I can't really tell from the error message.
Essentially a pre-existing AlmaLinux 9.2 aarch64 VM will now no longer
boot when using qemu-efi-aarch64/qemu-efi-arm 2023.05-1 in Sid.
As soon as I start the vm i get the following error message:
"""
BdsDxe: loading Boot0004 "AlmaLinux" from
HD(1,GPT,045389FA-D6F1-4E82-9801-60BC98C37B6D,0x800,0x12C000)/\EFI\almalinux\shimaa64.efi
BdsDxe: starting Boot0004 "AlmaLinux" from
HD(1,GPT,045389FA-D6F1-4E82-9801-60BC98C37B6D,0x800,0x12C000)/\EFI\almalinux\shimaa64.efi
Synchronous Exception at 0x000000013BE2C89C
Synchronous Exception at 0x000000013BE2C89C
"""
Downgrading to qemu-efi-aarch64_2022.11-6_all.deb fixes the issue.
Scripts to create the VM are here:
https://github.com/sej7278/virt-installs/tree/master/alma9_arm
Regards.
--
Simon John
dann frazier
Aug 1, 2023, 1:50:05 PM8/1/23
to
# first bad commit: [1c4dfadb4611ef511816dfdfbdb37d7d100b5a4b] ArmPkg/CpuDxe: Implement EFI memory attributes protocol
Reverting that from latest upstream seems to make the problem go
away. But the reason is not clear to me. This commit registers a
protocol, but it doesn't appear to use that protocol on its own.
I wonder if the AlmaLinux bootloader stack is trying to use it?
Reverting that from latest upstream seems to make the problem go
away. But the reason is not clear to me. This commit registers a
protocol, but it doesn't appear to use that protocol on its own.
I wonder if the AlmaLinux bootloader stack is trying to use it?
Simon John
Sep 11, 2023, 9:00:04 AM9/11/23
to
Sorry, I totally didn't see this reply.
I have the same issue on Fedora 38, here's a simple test script - note
it doesn't even get as far as launching the installer:
https://github.com/sej7278/virt-installs/blob/master/fedora38vb_arm.sh
Regards.
--
Simon John
I have the same issue on Fedora 38, here's a simple test script - note
it doesn't even get as far as launching the installer:
https://github.com/sej7278/virt-installs/blob/master/fedora38vb_arm.sh
Regards.
Simon John
dann frazier
Sep 22, 2023, 7:40:05 PM9/22/23
to
OK, I finally found some time to debug this. I debugged it with an
Ubuntu VM that used shim 15.7, but I suspect it is the same issue with
Fedora 38 and AlmaLinux 9.2.
shim 15.6 introduced the following commit:
commit 226fee25ffcbd29988399ba080c7706eb1d52251
Author: Peter Jones <REDACTED>
Date: Thu Dec 2 18:29:50 2021 -0500
PE Loader: support and require NX
This adds support in our PE loader for NX support utilizing the
EFI_MEMORY_ATTRIBUTE protocol. Specifically, it changes the loader such
that:
- binaries without the EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag set
in the Optional Header are rejected as EFI_UNSUPPORTED
- binaries with non-discardable sections that have both the
EFI_SCN_MEM_WRITE and EFI_SCN_MEM_EXECUTE flags set are rejected as
EFI_UNSUPPORTED
- if the EFI_MEMORY_ATTRIBUTE protocol is installed, then:
- sections without the EFI_SCN_MEM_READ flag set will be marked with
EFI_MEMORY_RP
- sections without the EFI_SCN_MEM_WRITE flag set will be marked with
EFI_MEMORY_RO
- sections without the EFI_SCN_MEM_EXECUTE flag set will be marked
with EFI_MEMORY_XP
Signed-off-by: Peter Jones <pjo...@redhat.com>
EDK2 didn't expose the EFI_MEMORY_ATTRIBUTE protocol for ARM until
2023.05-1, so at that point this shim code was activated. Unfortunately,
this shim code had a bug that causes this problem. Luckily it has
since been fixed in upstream git:
From c7b305152802c8db688605654f75e1195def9fd6 Mon Sep 17 00:00:00 2001
From: Nicholas Bishop <REDACTED>
Date: Mon, 19 Dec 2022 18:56:13 -0500
Subject: [PATCH] pe: Align section size up to page size for mem attrs
Setting memory attributes is generally done at page granularity, and
this is enforced by checks in `get_mem_attrs` and
`update_mem_attrs`. But unlike the section address, the section size
isn't necessarily aligned to 4KiB. Round up the section size to fix
this.
Signed-off-by: Nicholas Bishop <nichola...@google.com>
I've asked Ubuntu to pick this up (LP: #2036604). Please ask your
favorite guest OS distributions to pick it up as well.
Ubuntu VM that used shim 15.7, but I suspect it is the same issue with
Fedora 38 and AlmaLinux 9.2.
shim 15.6 introduced the following commit:
commit 226fee25ffcbd29988399ba080c7706eb1d52251
Author: Peter Jones <REDACTED>
Date: Thu Dec 2 18:29:50 2021 -0500
PE Loader: support and require NX
This adds support in our PE loader for NX support utilizing the
EFI_MEMORY_ATTRIBUTE protocol. Specifically, it changes the loader such
that:
- binaries without the EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag set
in the Optional Header are rejected as EFI_UNSUPPORTED
- binaries with non-discardable sections that have both the
EFI_SCN_MEM_WRITE and EFI_SCN_MEM_EXECUTE flags set are rejected as
EFI_UNSUPPORTED
- if the EFI_MEMORY_ATTRIBUTE protocol is installed, then:
- sections without the EFI_SCN_MEM_READ flag set will be marked with
EFI_MEMORY_RP
- sections without the EFI_SCN_MEM_WRITE flag set will be marked with
EFI_MEMORY_RO
- sections without the EFI_SCN_MEM_EXECUTE flag set will be marked
with EFI_MEMORY_XP
Signed-off-by: Peter Jones <pjo...@redhat.com>
EDK2 didn't expose the EFI_MEMORY_ATTRIBUTE protocol for ARM until
2023.05-1, so at that point this shim code was activated. Unfortunately,
this shim code had a bug that causes this problem. Luckily it has
since been fixed in upstream git:
From c7b305152802c8db688605654f75e1195def9fd6 Mon Sep 17 00:00:00 2001
From: Nicholas Bishop <REDACTED>
Date: Mon, 19 Dec 2022 18:56:13 -0500
Subject: [PATCH] pe: Align section size up to page size for mem attrs
Setting memory attributes is generally done at page granularity, and
this is enforced by checks in `get_mem_attrs` and
`update_mem_attrs`. But unlike the section address, the section size
isn't necessarily aligned to 4KiB. Round up the section size to fix
this.
Signed-off-by: Nicholas Bishop <nichola...@google.com>
I've asked Ubuntu to pick this up (LP: #2036604). Please ask your
favorite guest OS distributions to pick it up as well.
Simon John
Sep 23, 2023, 6:20:05 AM9/23/23
to
Thanks for looking into this!
I was hoping we could revert the offending edk2 commit in debian rather
than getting every guest os vendor to update their shim - which would
mean only fresh installs would work.
Red Hat seem to have merged the fix this year:
https://github.com/rhboot/shim/commit/c7b305152802c8db688605654f75e1195def9fd6
But there's not be a new rhel/fedora rpm in well over a year, still 15.6
--
Simon John
I was hoping we could revert the offending edk2 commit in debian rather
than getting every guest os vendor to update their shim - which would
mean only fresh installs would work.
Red Hat seem to have merged the fix this year:
https://github.com/rhboot/shim/commit/c7b305152802c8db688605654f75e1195def9fd6
But there's not be a new rhel/fedora rpm in well over a year, still 15.6
Simon John
dann frazier
Sep 23, 2023, 12:10:04 PM9/23/23
to
On Sat, Sep 23, 2023 at 11:15:45AM +0100, Simon John wrote:
> Thanks for looking into this!
>
> I was hoping we could revert the offending edk2 commit in debian rather than
> getting every guest os vendor to update their shim - which would mean only
> fresh installs would work.
>
> Red Hat seem to have merged the fix this year:
>
> https://github.com/rhboot/shim/commit/c7b305152802c8db688605654f75e1195def9fd6
>
> But there's not be a new rhel/fedora rpm in well over a year, still 15.6
Yeah, shim updates are hard to do, so let's give distributions some
> Thanks for looking into this!
>
> I was hoping we could revert the offending edk2 commit in debian rather than
> getting every guest os vendor to update their shim - which would mean only
> fresh installs would work.
>
> Red Hat seem to have merged the fix this year:
>
> https://github.com/rhboot/shim/commit/c7b305152802c8db688605654f75e1195def9fd6
>
> But there's not be a new rhel/fedora rpm in well over a year, still 15.6
time to update. I've reverted the change in edk2 for now, but I do
plan to restore it by early 2024.
0 new messages