Tue 28 Feb 2017 12:18:53 PM UTC, original submission:
When executing GRUB/aarch64 on recent EDK2 UEFI builds that enable a newly
introduced memory protection feature that results in only memory regions of
types EfiBootServicesCode, EfiRuntimeServicesCode and EfiLoaderCode being
mapped executable, a crash like the following may occur:
FSOpen: Open '\EFI\fedora\grubaa64.efi' Success
Synchronous Exception at 0x00000001380F7400
X0 0x000000013A6EEA98 X1 0x000000013BFF0018 X2 0x00000001380F7400 X3 0x00000000000FD000
X4 0x0000000000000000 X5 0x0000000000000000 X6 0x0000000138362AF4 X7 0x0000000000000000
X8 0x000000013C01F548 X9 0x0000000200000000 X10 0x00000001380F6000 X11 0x00000001382F3FFF
X12 0x0000000000000000 X13 0x0000000000000008 X14 0x0000000000000000 X15 0x0000000000000000
X16 0x000000013EC6ABD0 X17 0x0000000000000000 X18 0x0000000000000000 X19 0x0000000138CDB698
X20 0x000000013A746E18 X21 0x0000000000000000 X22 0x0000000000000000 X23 0x0000000000000000
X24 0x0000000000000000 X25 0x0000000000000000 X26 0x0000000000000000 X27 0x0000000000000000
X28 0x0000000000000000 FP 0x000000013EC6AA50 LR 0x00000001382F80F8
[...]
SP 0x000000013EC6AA50 ELR 0x00000001380F7400 SPSR 0x60000205 FPSR 0x00000000
ESR 0x8600000E FAR 0x00000001380F7400
ESR : EC 0x21 IL 0x1 ISS 0x0000000E
Instruction abort: Permission fault, second level
This is most likely caused by GRUB attempting to execute code from a region that
was allocated as EfiLoaderData, which appears to be the type used for all memory
allocations performed by GRUB.
To interoperate correctly in a context such as this one, the easy fix is to
replace all EfiLoaderData allocations with EfiLoaderCode allocations. The
proper fix, however, would be to selectively use EfiLoaderCode allocations
only for bits that require executable permissions.
|