From nobody Tue May 7 09:26:34 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zoho.com; dkim=fail spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 149094962725499.6929657588961; Fri, 31 Mar 2017 01:40:27 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id EDD2821A04839; Fri, 31 Mar 2017 01:40:25 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 956F421A04830 for ; Fri, 31 Mar 2017 01:40:24 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id k6so89886118wre.2 for ; Fri, 31 Mar 2017 01:40:24 -0700 (PDT) Received: from localhost.localdomain ([160.171.180.74]) by smtp.gmail.com with ESMTPSA id v14sm1996945wmv.24.2017.03.31.01.40.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 01:40:22 -0700 (PDT) X-Original-To: edk2-devel@lists.01.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=Jz1IcyXf5P4thDnZNM8IrFbBL2nljeb2fAWzYLZ4BOY=; b=K7ycE/PmnFhWoAstDZqyvq3+Id8d+iBZYRpQycp/OZAE0yL/s/sRCt6+dgVqSjpYGI hZF/P7BeQKeNeQEGqQglkzE3tLyCuo/C/DwjEkZR4mSg8Qvcu0nTHI0YbfKWWYuvRf6G k3olonCSjYJ7srA9vLb+hULFJGDPX17lV/fpo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Jz1IcyXf5P4thDnZNM8IrFbBL2nljeb2fAWzYLZ4BOY=; b=rXPWoOONchmcymXr0YXkP9Zoxy83DLa7TEYY1eE3MiIftwNhDqacE4pHeXATjGLroc 6v3LPHTNGn/AKrH7blP0iFK57SdsMYapfo003uBq5TrppxBCZ/8a5fhhdsU1vXLxQvis ugIHhkX6Gkw82J9llxM1GShZhwDQo2veYSh8J7dFODwgH963tuoDWH50GjyieLaHRd2o 8TiiJVL6l2IfuyqpQ7+GwOGkNZRHMvo+Bh7hmYIZ1+bnWTchIS+NzfvZSDQfSVkPmmyp 4q8PSX+j6y4JMQ0aXg3NvebUOoUa0DoD4z97HDhm+kmo9Ry1r5DVJOC7PZXM2IWtm4FJ VYiw== X-Gm-Message-State: AFeK/H2Z86Q8XvEQsffJkfxg8dADkXT+NI973ywUCSGddFFtZzeu37QX8nJFJmQMIVdXejVS X-Received: by 10.28.134.70 with SMTP id i67mr2100555wmd.124.1490949622971; Fri, 31 Mar 2017 01:40:22 -0700 (PDT) From: Ard Biesheuvel To: edk2-devel@lists.01.org, leif.lindholm@linaro.org Date: Fri, 31 Mar 2017 09:40:13 +0100 Message-Id: <20170331084013.4203-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 Subject: [edk2] [PATCH v2] BaseTools/GCC AARCH64: force disable PIC code generation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marc.zyngier@arm.com, lersek@redhat.com, liming.gao@intel.com, Ard Biesheuvel MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" 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 Acked-by: Laszlo Ersek --- 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.t= emplate 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 =3D DEF(GCC_ALL_CC= _FLAGS) -mno-red-zone -Wno-ad DEFINE GCC_IPF_CC_FLAGS =3D DEF(GCC_ALL_CC_FLAGS) -minline-int-= divide-min-latency DEFINE GCC_ARM_CC_FLAGS =3D DEF(GCC_ALL_CC_FLAGS) -mlittle-endi= an -mabi=3Daapcs -fno-short-enums -funsigned-char -ffunction-sections -fdat= a-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb -mfloat-a= bi=3Dsoft DEFINE GCC_ARM_CC_XIPFLAGS =3D -mno-unaligned-access -DEFINE GCC_AARCH64_CC_FLAGS =3D DEF(GCC_ALL_CC_FLAGS) -mlittle-endi= an -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fda= ta-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables +DEFINE GCC_AARCH64_CC_FLAGS =3D DEF(GCC_ALL_CC_FLAGS) -mlittle-endi= an -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fda= ta-sections -fno-builtin -Wno-address -fno-asynchronous-unwind-tables -fno-= pic DEFINE GCC_AARCH64_CC_XIPFLAGS =3D -mstrict-align DEFINE GCC_DLINK_FLAGS_COMMON =3D -nostdlib --pie DEFINE GCC_DLINK2_FLAGS_COMMON =3D -Wl,--script=3D$(EDK_TOOLS_PATH)/Sc= ripts/GccBase.lds --=20 2.9.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel