aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/firmware/efi/apple-properties.c
diff options
context:
space:
mode:
authorArd Biesheuvel <ardb@kernel.org>2020-02-10 19:29:36 +0100
committerArd Biesheuvel <ardb@kernel.org>2020-02-22 23:37:37 +0100
commitb92165d2ba869a9d0b43d00a5676c4b341194c88 (patch)
tree141967686b12a5d5a9a1998ab55841380db661a7 /drivers/firmware/efi/apple-properties.c
parentefi/bgrt: Accept BGRT tables with a version of 0 (diff)
downloadlinux-dev-b92165d2ba869a9d0b43d00a5676c4b341194c88.tar.xz
linux-dev-b92165d2ba869a9d0b43d00a5676c4b341194c88.zip
efi/libstub/arm64: Use 1:1 mapping of RT services if property table exists
The UEFI spec defines (and deprecates) a misguided and shortlived memory protection feature that is based on splitting memory regions covering PE/COFF executables into separate code and data regions, without annotating them as belonging to the same executable image. When the OS assigns the virtual addresses of these regions, it may move them around arbitrarily, without taking into account that the PE/COFF code sections may contain relative references into the data sections, which means the relative placement of these segments has to be preserved or the executable image will be corrupted. The original workaround on arm64 was to ensure that adjacent regions of the same type were mapped adjacently in the virtual mapping, but this requires sorting of the memory map, which we would prefer to avoid. Considering that the native physical mapping of the PE/COFF images does not suffer from this issue, let's preserve it at runtime, and install it as the virtual mapping as well. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Diffstat (limited to 'drivers/firmware/efi/apple-properties.c')
0 files changed, 0 insertions, 0 deletions