From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 2ACDE1A1DF4 for ; Mon, 22 Aug 2016 03:14:28 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id q128so113840113wma.1 for ; Mon, 22 Aug 2016 03:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=RknZPN4oUEB1lYNpTCzyObTgygkJ/EpCeUzrLeXYx0w=; b=kTHg0rZbm6TTS4mlNt5vL7uWxnMWk33hzBSC9Fjl1Oc0HXqqd7KHUN2fnSbCIunDXO difCOxhqiboRrQOIhpSJ1x8XSZvkKhkysi46pkr/L5n4aeZ/KiZsARnc5/QLJsoRTbuF TGXFeM5zKPj6EbtRY/J25dIZwvLvGP/97vyGQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=RknZPN4oUEB1lYNpTCzyObTgygkJ/EpCeUzrLeXYx0w=; b=RpgxoDuGayJdpoqK0OsozWZ/pqEypXM2qtnZKtA3QBm1toOcXLq3zdqyvYroh7vK0F +g6jx0u85Zagz7METy/ogCWuljllT3dIORZdZ+VJmstV8+xzGhY0BTw9tVPOY4Vwu3vM s+tru6ivb0KQGm7e7t6KARhQDoyQFxGisqIhLe7wbqLAhP2FDeWVAgnWTcEuxwH8715p Da7SUHZBqQUCtrjz1IpIl9+LPR02WZhdj+1waqyoeVxwvir4tG2fZuJVYpDphIXyktyN DrO+cnVInD/mTYEklIAqx+ln/cVov9qpVptBQ245PYOmWEPXTIjMBLSSUNv+kGAVKojJ OYfg== X-Gm-Message-State: AEkooutAuAsQ+HnluSfgW4y4nC8pzWwUXI/xR2FluLVXSLs8IDJc2Eh7yrGUO/UwjlWzkULa X-Received: by 10.28.32.77 with SMTP id g74mr13862629wmg.45.1471860866672; Mon, 22 Aug 2016 03:14:26 -0700 (PDT) Received: from localhost.localdomain (2.178.14.62.static.jazztel.es. [62.14.178.2]) by smtp.gmail.com with ESMTPSA id i3sm23060258wjd.31.2016.08.22.03.14.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Aug 2016 03:14:25 -0700 (PDT) From: Ard Biesheuvel To: edk2-devel@lists.01.org, liming.gao@intel.com, steven.shi@intel.com, yonghong.zhu@intel.com Cc: Ard Biesheuvel Date: Mon, 22 Aug 2016 12:14:21 +0200 Message-Id: <1471860861-32600-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Subject: [PATCH] BaseTools/GenFw: ignore dynamic RELA sections X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 10:14:28 -0000 When building PIE (ET_DYN) executables, an additional RELA section is emitted (in addition to the per-section .rela.text and .rela.data sections) that is intended to be resolved at runtime by a ET_DYN compatible loader. At the moment, due to the fact that we don't support GOT based relocations, this dynamic RELA section only contains relocations that are redundant, i.e., each R_xxx_RELATIVE relocation it contains duplicates a R_xxx_ABS64 relocation appear in .rela.text or .rela.data, and so we can simply ignore this section (and we already ignore it in practice due to the fact that it points to the NULL section, which has the SHF_ALLOC bit cleared) For example, Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .text PROGBITS 0000000000000240 000000c0 000000000000427c 0000000000000008 AX 0 0 64 [ 2] .rela.text RELA 0000000000000000 00009310 0000000000001bf0 0000000000000018 I 7 1 8 [ 3] .data PROGBITS 00000000000044c0 00004340 00000000000046d0 0000000000000000 WA 0 0 64 [ 4] .rela.data RELA 0000000000000000 0000af00 0000000000000600 0000000000000018 I 7 3 8 [ 5] .rela RELA 0000000000008bc0 00008a10 0000000000000600 0000000000000018 0 0 8 [ 6] .shstrtab STRTAB 0000000000000000 0000b500 0000000000000037 0000000000000000 0 0 1 [ 7] .symtab SYMTAB 0000000000000000 00009010 0000000000000210 0000000000000018 8 17 8 [ 8] .strtab STRTAB 0000000000000000 00009220 00000000000000eb 0000000000000000 0 0 1 Relocation section '.rela.data' at offset 0xaf00 contains 64 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000004800 000100000001 R_X86_64_64 0000000000000240 .text + 3f5b 000000004808 000100000001 R_X86_64_64 0000000000000240 .text + 3f63 000000004810 000100000001 R_X86_64_64 0000000000000240 .text + 3f79 000000004818 000100000001 R_X86_64_64 0000000000000240 .text + 3f90 000000004820 000100000001 R_X86_64_64 0000000000000240 .text + 3fa6 ... Relocation section '.rela' at offset 0x8a10 contains 64 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000004800 000000000008 R_X86_64_RELATIVE 419b 000000004808 000000000008 R_X86_64_RELATIVE 41a3 000000004810 000000000008 R_X86_64_RELATIVE 41b9 000000004818 000000000008 R_X86_64_RELATIVE 41d0 000000004820 000000000008 R_X86_64_RELATIVE 41e6 000000004828 000000000008 R_X86_64_RELATIVE 41ff ... Note that GOT based relocations result in entries that *only* appear in the dynamic .rela section and not in .rela.text or .rela.data. This means two things for supporting GOT based relocations: - we should check that a dynamic RELA section exists - we should filter out duplicates between .rela and .rela.xxx, to prevent emitting duplicate fixups into the PE/COFF .reloc section. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Source/C/GenFw/Elf64Convert.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c index 708c1a1d91a7..acf435712146 100644 --- a/BaseTools/Source/C/GenFw/Elf64Convert.c +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c @@ -683,6 +683,20 @@ WriteSections64 ( } // + // If this is a ET_DYN (PIE) executable, we will encounter a dynamic SHT_RELA + // section that applies to the entire binary, and which will have its section + // index set to #0 (which is a NULL section with the SHF_ALLOC bit cleared). + // + // In the absence of GOT based relocations (which we currently don't support), + // this RELA section will mostly contain R_xxx_RELATIVE relocations, one for + // every R_xxx_ABS64 relocation appearing in the per-section RELA sections. + // (i.e., .rela.text and .rela.data) + // + if (RelShdr->sh_info == 0) { + continue; + } + + // // Relocation section found. Now extract section information that the relocations // apply to in the ELF data and the new COFF data. // -- 2.7.4