diff options
author | Ard Biesheuvel <ard.biesheuvel@linaro.org> | 2017-03-31 09:22:56 +0100 |
---|---|---|
committer | Ard Biesheuvel <ard.biesheuvel@linaro.org> | 2017-03-31 10:34:34 +0100 |
commit | c2d56a894b3211bd96a63f388932ea8b38ae3463 (patch) | |
tree | 178b909a61639916c8731a95ebc8f57bc746b752 /BaseTools/Source/Python/Table/TableFile.py | |
parent | af8388059a2805f61dd5d06c7cad21bb90a72526 (diff) | |
download | edk2-c2d56a894b3211bd96a63f388932ea8b38ae3463.tar.gz edk2-c2d56a894b3211bd96a63f388932ea8b38ae3463.tar.bz2 edk2-c2d56a894b3211bd96a63f388932ea8b38ae3463.zip |
BaseTools/GCC AARCH64: force disable PIC code generation
As a security measure, some distro toolchains now default to PIC code
generation, allowing executables (as opposed to shared libraries) using
the objects to be built as PIE binaries, which can be loaded at a random
virtual offset.
However, our ELF to PE/COFF generation code does not deal with the
resulting relocation types (i.e., GOT based), and so the use of PIC code
leads to GenFw errors.
Given that
a) our non-PIC PE/COFF executables are already relocatable,
b) PIC code leads to all symbol references to be indirected via GOT
entries containing absolute addresses, each requiring an entry in the
relocation table,
c) the AArch64 ISA makes it perfectly feasible to built PIE executables
from non-PIC code,
there is absolutely no upside to using PIC code for building EDK2 modules,
and so we're better off simply disabling it unconditionally.
Note that when running under the OS, the GOT has an additional advantage,
i.e., that all .text/.rodata pages remain clean and so can be shared between
processes. This does not apply to the UEFI environment, however.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Diffstat (limited to 'BaseTools/Source/Python/Table/TableFile.py')
0 files changed, 0 insertions, 0 deletions