Skip to content

aarch64: page-align the UEFI loader image - #2182

Merged
francescolavra merged 1 commit into
nanovms:masterfrom
AngeloRubens:aarch64-uefi-align
Oct 11, 2026
Merged

francescolavra merged 1 commit into
nanovms:masterfrom
AngeloRubens:aarch64-uefi-align

Conversation

@AngeloRubens

@AngeloRubens AngeloRubens commented Aug 29, 2026 •

Copy link
Copy Markdown
Contributor

The PE header of the aarch64 UEFI loader declares a SectionAlignment and a
FileAlignment of 0x1000, but _start is aligned to 8, so SizeOfHeaders and the
virtual address of .text both come out as 0x200. The format does not allow
either of them to be unaligned with respect to the values declared above.

Firmware that enforces this when it applies memory attributes to a loaded image
rejects the loader before it runs. The edk2 build that Oracle Cloud
Infrastructure ships as of 2026-05-22 asserts in DxeCore:

UpdateRegionMapping RegionStart: 0x33E357000 or RegionLength: 0x200 are not page aligned
SetUefiImageMemoryAttributes failed on 33E357000 of length 200 - Invalid Parameter
ASSERT [DxeCore] MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c(281)

Aligning _start to a page makes the declared and the actual layout agree. Every
field that locates .text derives from _start - IMAGE_BASE, so they all move
together.

Tested on a VM.Standard.A1.Flex instance in eu-milan-1. Before the change the
firmware asserts as above; after it, the loader runs and reaches
ExitBootServices.

Console of the instance, captured with oci compute console-history, before the
change:

Loading Boot0002 "UEFI ORACLE BlockVolume " from PciRoot(0x0)/Pci(0x5,0x7)/Pci(0x0,0x0)/Scsi(0x0,0x1)
UpdateRegionMapping RegionStart: 0x33E357000 or RegionLength: 0x200 are not page aligned!
SetUefiImageMemoryAttributes failed on 33E357000 of length 200 with attributes 4008 - Invalid Parameter

ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [DxeCore] /builddir/build/BUILD/edk2-20260522/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c(281)

The same image on a 1 OCPU / 1 GB shape fails identically, only the address
differs (0x7E358000), so the shape of the instance is not a factor.

After the change, on the same shape, the firmware starts the image and the
loader reaches the end of its work:

Loading Boot0002 "UEFI ORACLE BlockVolume " from PciRoot(0x0)/Pci(0x5,0x7)/Pci(0x0,0x0)/Scsi(0x0,0x1)
Starting Boot0002 "UEFI ORACLE BlockVolume " from PciRoot(0x0)/Pci(0x5,0x7)/Pci(0x0,0x0)/Scsi(0x0,0x1)
EFI ExitBootServices: Called.

Header fields before and after, read from the built binary:

SizeOfHeaders   0x200    ->  0x1000
.text VirtualAddress and PointerToRawData   0x200  ->  0x1000

@francescolavra francescolavra left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In both the commit message and the PR description, the statement "The header grows into the space .text no longer occupies, so the loader does not get any larger" is wrong and misleading. The loader is keeping the previous size just by chance. Remove all mentions of the loader size.

Comment thread src/aarch64/uefi-crt0.s Outdated
The PE header declares a SectionAlignment and a FileAlignment of 0x1000,
and every field that locates .text is _start - IMAGE_BASE: SizeOfHeaders,
AddressOfEntryPoint, BaseOfCode, and the section's VirtualAddress and
PointerToRawData. With _start aligned to 8 those fields read 0x200, which
the format does not allow of either a section's virtual address or
SizeOfHeaders.

Firmware that enforces the alignment when it applies memory attributes to
a loaded image rejects the loader and asserts in DxeCore before it runs;
the edk2 build Oracle Cloud Infrastructure ships as of 2026-05-22 does.

Aligning _start to a page makes the declared and actual layout agree.
@francescolavra
francescolavra merged commit 105d483 into nanovms:master Oct 11, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants