From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::442; helo=mail-wr1-x442.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 809E321198CC2 for ; Tue, 11 Dec 2018 01:37:20 -0800 (PST) Received: by mail-wr1-x442.google.com with SMTP id 96so13332262wrb.2 for ; Tue, 11 Dec 2018 01:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=se8UsiLMKJumxugeYKzEZCfWDnU3uH7+WdfqF0w7ygY=; b=FNLYBhRamLJDDrwQSA/3Y0Yi3+cpWloOFpU/hUfTsSs11kGHfO7ZbmhAXoKuDtDOe1 H9IO+pmYqqp/jT1x1PMcmxL0/BnwUxHXcKKas3/54/plMDN9Fs/W7GNtzYSdOiviebib GvfUflLl1lDTxeOYItXbyG8IxPFE5ro8aVq5s= 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:mime-version :content-transfer-encoding; bh=se8UsiLMKJumxugeYKzEZCfWDnU3uH7+WdfqF0w7ygY=; b=GgQcbKMRh5iufeJiJVteik0i+op7KhCAnSG9Larn3MWQ//YYgKBqg9xO98ZJ0ue+St VQI6irh0okbWG0tXzHvBnZ8OZaOzmbvMTvXfBvYsmDxJyvyvI8/VeDndgtdAWi8s5Yre 0lRzsSqJSa+UVkHD8pg4e519FluEwje8zyodP48Zv9netFIdB4gEdkmL0VZ9B0stPgf9 Q33pE67ATci4hYG522/CcvjanmqBz6ivw0E758HR681gpPS4Odl/1QHiGvzU5z6Sq4c8 9rIyN6Cz7yTaYOrlDYjzjByCODp1+OoaLzY1vru2tI6BEv0wnlIZThQMuUpkpnTYfgtb UyeA== X-Gm-Message-State: AA+aEWYKhBN1Gi+Nv2g+GySz5BVJ3Wu14Nydc9hYGlBdr9YU+GqLqH2y e/UiKp4wCtyrabBEoVhRf6myognBk86i+w== X-Google-Smtp-Source: AFSGD/WBUgW/IUMldNiQ+Uj2pS7zFguMs3X4MuL/L4H45RGjp3yv4l/1BZL2GhwqPYg/lmtMdK0czg== X-Received: by 2002:a5d:5443:: with SMTP id w3mr11817140wrv.4.1544521038357; Tue, 11 Dec 2018 01:37:18 -0800 (PST) Received: from harold.home ([2a01:cb1d:112:6f00:8c3:6b9d:cbc9:58c6]) by smtp.gmail.com with ESMTPSA id y34sm42589313wrd.68.2018.12.11.01.37.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 01:37:17 -0800 (PST) From: Ard Biesheuvel To: edk2-devel@lists.01.org Cc: lersek@redhat.com, Ard Biesheuvel , Bob Feng , Liming Gao , Leif Lindholm Date: Tue, 11 Dec 2018 10:37:15 +0100 Message-Id: <20181211093715.6048-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.19.2 MIME-Version: 1.0 Subject: [PATCH] BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 09:37:20 -0000 Content-Transfer-Encoding: 8bit We currently permit R_ARM_GOT_PREL relocations in the ELF32 conversion routines, under the assumption that relative relocations are fine as long as the section layout is the same between ELF and PE/COFF. However, as is the case with any proxy generating relocation, it is up to the linker to emit an entry in the GOT table and populate it with the correct absolute address, which should also be fixed up at PE/COFF load time. Unfortunately, the relocations covering the GOT section are not emitted into the static relocation sections processed by GenFw, but only in the dynamic relocation section as a R_ARM_RELATIVE relocation, and so GenFw fails to emit the correct PE/COFF relocation data for GOT entries. Since GOT indirection is pointless anyway for PE/COFF modules running in UEFI context, let's just drop the references to R_ARM_GOT_PREL from GenFw, resulting in a build time failure rather than a runtime failure if such relocations do occur. Cc: Bob Feng Cc: Liming Gao Cc: Leif Lindholm Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Without this patch, CLANG38 builds of ArmVirtQemuKernel-ARM (in LTO mode) succeed, but the resulting binaries are broken. This is due to the fact that the PIE linker running in LTO mode insists on emitting GOT based relocations, while we don't have the code to fix up the contents of the GOT. This change puts it in line with the AARCH64 build of the same platform/toolchains, which chokes on GOT based relocations as well. Since the use of the PIE linker is a peculiarity of ArmVirtQemuKernel/ArmVirtXen, and the fact that it is impossible to prevent the linker from emitting GOT based relocations, let's not go out of our way to fix it in the tools, but just drop CLANG38 support from those platforms. BaseTools/Source/C/GenFw/Elf32Convert.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c b/BaseTools/Source/C/GenFw/Elf32Convert.c index 3d7de6d5c123..23e8065756e6 100644 --- a/BaseTools/Source/C/GenFw/Elf32Convert.c +++ b/BaseTools/Source/C/GenFw/Elf32Convert.c @@ -837,7 +837,6 @@ WriteSections32 ( case R_ARM_LDC_PC_G0: case R_ARM_LDC_PC_G1: case R_ARM_LDC_PC_G2: - case R_ARM_GOT_PREL: case R_ARM_THM_JUMP11: case R_ARM_THM_JUMP8: case R_ARM_TLS_GD32: @@ -964,7 +963,6 @@ WriteRelocations32 ( case R_ARM_LDC_PC_G0: case R_ARM_LDC_PC_G1: case R_ARM_LDC_PC_G2: - case R_ARM_GOT_PREL: case R_ARM_THM_JUMP11: case R_ARM_THM_JUMP8: case R_ARM_TLS_GD32: -- 2.19.2