public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: edk2-devel@lists.01.org, leif.lindholm@linaro.org
Cc: lersek@redhat.com, marc.zyngier@arm.com, yonghong.zhu@intel.com,
	liming.gao@intel.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH v2] BaseTools/GCC AARCH64: force disable PIC code generation
Date: Fri, 31 Mar 2017 09:40:13 +0100	[thread overview]
Message-ID: <20170331084013.4203-1-ard.biesheuvel@linaro.org> (raw)

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



             reply	other threads:[~2017-03-31  8:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31  8:40 Ard Biesheuvel [this message]
2017-03-31  8:59 ` [PATCH v2] BaseTools/GCC AARCH64: force disable PIC code generation Laszlo Ersek
2017-03-31  9:39   ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170331084013.4203-1-ard.biesheuvel@linaro.org \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox