[edk2] [PATCH v2] BaseTools/GCC AARCH64: force disable PIC code generation

Ard Biesheuvel posted 1 patch 7 years ago
Failed in applying to current master (apply log)
BaseTools/Conf/tools_def.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[edk2] [PATCH v2] BaseTools/GCC AARCH64: force disable PIC code generation
Posted by Ard Biesheuvel 7 years ago
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>
---
 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
index 0aabdeb2d973..2c5cd5808912 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4341,7 +4341,7 @@ DEFINE GCC_X64_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-ad
 DEFINE GCC_IPF_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-min-latency
 DEFINE GCC_ARM_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb -mfloat-abi=soft
 DEFINE GCC_ARM_CC_XIPFLAGS         = -mno-unaligned-access
-DEFINE GCC_AARCH64_CC_FLAGS        = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables
+DEFINE GCC_AARCH64_CC_FLAGS        = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables -fno-pic
 DEFINE GCC_AARCH64_CC_XIPFLAGS     = -mstrict-align
 DEFINE GCC_DLINK_FLAGS_COMMON      = -nostdlib --pie
 DEFINE GCC_DLINK2_FLAGS_COMMON     = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
-- 
2.9.3

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] BaseTools/GCC AARCH64: force disable PIC code generation
Posted by Laszlo Ersek 7 years ago
On 03/31/17 10:40, Ard Biesheuvel wrote:
> 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>
> ---
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
> index 0aabdeb2d973..2c5cd5808912 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4341,7 +4341,7 @@ DEFINE GCC_X64_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-ad
>  DEFINE GCC_IPF_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-min-latency
>  DEFINE GCC_ARM_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb -mfloat-abi=soft
>  DEFINE GCC_ARM_CC_XIPFLAGS         = -mno-unaligned-access
> -DEFINE GCC_AARCH64_CC_FLAGS        = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables
> +DEFINE GCC_AARCH64_CC_FLAGS        = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables -fno-pic
>  DEFINE GCC_AARCH64_CC_XIPFLAGS     = -mstrict-align
>  DEFINE GCC_DLINK_FLAGS_COMMON      = -nostdlib --pie
>  DEFINE GCC_DLINK2_FLAGS_COMMON     = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
> 

Sounds convincing enough to me. I find it quite annoying that such an
important property of code generation (-fpic or -fno-pic by default)
varies across distros. Well, security.

Acked-by: Laszlo Ersek <lersek@redhat.com>

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] BaseTools/GCC AARCH64: force disable PIC code generation
Posted by Ard Biesheuvel 7 years ago
On 31 March 2017 at 09:59, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/31/17 10:40, Ard Biesheuvel wrote:
>> 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>
>> ---
>>  BaseTools/Conf/tools_def.template | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
>> index 0aabdeb2d973..2c5cd5808912 100755
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -4341,7 +4341,7 @@ DEFINE GCC_X64_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-ad
>>  DEFINE GCC_IPF_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-min-latency
>>  DEFINE GCC_ARM_CC_FLAGS            = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb -mfloat-abi=soft
>>  DEFINE GCC_ARM_CC_XIPFLAGS         = -mno-unaligned-access
>> -DEFINE GCC_AARCH64_CC_FLAGS        = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables
>> +DEFINE GCC_AARCH64_CC_FLAGS        = DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections -fdata-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables -fno-pic
>>  DEFINE GCC_AARCH64_CC_XIPFLAGS     = -mstrict-align
>>  DEFINE GCC_DLINK_FLAGS_COMMON      = -nostdlib --pie
>>  DEFINE GCC_DLINK2_FLAGS_COMMON     = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
>>
>
> Sounds convincing enough to me. I find it quite annoying that such an
> important property of code generation (-fpic or -fno-pic by default)
> varies across distros. Well, security.
>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
>

Thanks, pushed as c2d56a894b32
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel