Patch "arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions" has been added to the 4.2-stable tree
Subsystems (3)
This is a note to let you know that I've just added the patch titled
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
to the 4.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-efi-fix-boot-crash-by-not-padding-between-efi_memory_runtime-regions.patch
and it can be found in the queue-4.2 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
0ce3cc008ec04258b6a6314b09f1a6012810881aMon Sep 17 00:00:00 2001
From: Ard Biesheuvel <[email protected]>
Date: Fri, 25 Sep 2015 23:02:19 +0100
Subject: arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
From: Ard Biesheuvel <[email protected]>
commit 0ce3cc008ec04258b6a6314b09f1a6012810881a upstream.
The new Properties Table feature introduced in UEFIv2.5 may split memory regions that cover PE/COFF memory images into separate code and data regions. Since these regions only differ in the type (runtime code vs runtime data) and the permission bits, but not in the memory type attributes (UC/WC/WT/WB), the spec does not require them to be aligned to 64 KB.
Since the relative offset of PE/COFF .text and .data segments cannot be changed on the fly, this means that we can no longer pad out those regions to be mappable using 64 KB pages. Unfortunately, there is no annotation in the UEFI memory map that identifies data regions that were split off from a code region, so we must apply this logic to all adjacent runtime regions whose attributes only differ in the permission bits.
So instead of rounding each memory region to 64 KB alignment at both ends, only round down regions that are not directly preceded by another runtime region with the same type attributes. Since the UEFI spec does not mandate that the memory map be sorted, this means we also need to sort it first.
Note that this change will result in all EFI_MEMORY_RUNTIME regions whose start addresses are not aligned to the OS page size to be mapped with executable permissions (i.e., on kernels compiled with 64 KB pages). However, since these mappings are only active during the time that UEFI Runtime Services are being invoked, the window for abuse is rather small.
--- arch/arm64/kernel/efi.c | 3 - drivers/firmware/efi/libstub/arm-stub.c | 86 ++++++++++++++++++++++++++------ 2 files changed, 74 insertions(+), 15 deletions(-)
arch/arm64/kernel/efi.c +2 -1
@@ -258,7 +258,8 @@ static bool __init efi_virtmap_init(void*/ if (!is_normal_ram (md)) prot =__pgprot (PROT_DEVICE_nGnRE); -else if (md->type ==EFI_RUNTIME_SERVICES_CODE ) +else if (md->type ==EFI_RUNTIME_SERVICES_CODE || + !PAGE_ALIGNED (md->phys_addr)) prot =PAGE_KERNEL_EXEC ;else prot =PAGE_KERNEL ;
drivers/firmware/efi/libstub/arm-stub.c +72 -14
117 lines not on this page · raw message
Patches currently in stable-queue which might be from [email protected] are
queue-4.2/x86-efi-fix-boot-crash-by-mapping-efi-memmap-entries-bottom-up-at-runtime-instead-of-top-down.patch queue-4.2/arm64-efi-fix-boot-crash-by-not-padding-between-efi_memory_runtime-regions.patch queue-4.2/arm-8429-1-disable-gcc-sra-optimization.patch