From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web10.1799.1573117589623113613 for ; Thu, 07 Nov 2019 01:06:29 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: srs0=vjqq=y7=linaro.org=ard.biesheuvel@kernel.org) Received: from e123331-lin.home (lfbn-mar-1-643-104.w90-118.abo.wanadoo.fr [90.118.215.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F12372084D; Thu, 7 Nov 2019 09:06:27 +0000 (UTC) From: "Ard Biesheuvel" To: devel@edk2.groups.io Cc: eugene@hp.com, Ard Biesheuvel Subject: [PATCH 1/1] BaseTools/GenFw AARCH64: disregard ADRP instructions that are patched already Date: Thu, 7 Nov 2019 10:06:18 +0100 Message-Id: <20191107090618.15813-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.17.1 In order to permit the use of compilers that only implement the small code model [which involves the use of ADRP instructions that require 4 KB segment alignment] for generating PE/COFF binaries with a small footprint, we patch ADRP instructions into ADR instructions while doing the ELF to PE/COFF conversion. As it turns out, the linker may be doing the same, but for different reasons: there is a silicon erratum #843419 for ARM Cortex-A53 which affects ADRP instructions appearing at a certain offset in memory, and one of the mitigations for this erratum is to patch them into ADR instructions at link time if the symbol reference is within -/+ 1 MB. However, the LD linker fails to update the static relocation tables, and so we end up with an ADR instruction in the fully linked binary, but with a relocation entry in the RELA section identifying it as an ADRP instruction. Since the linker has already updated the symbol reference, there is no handling needed in GenFw for such instructions, and we can simply treat it as an ordinary ADR. However, since it is guaranteed to be accompanied by an add or load instruction with a LO12 relocation referencing the same symbol, the section offset check we apply to ADR instructions is going to take place anyway, so we can just disregard the ADR instruction entirely. Reported-by: Eugene Cohen Suggested-by: Eugene Cohen Signed-off-by: Ard Biesheuvel --- BaseTools/Source/C/GenFw/Elf64Convert.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c index d574300ac4fe..d623dce1f9da 100644 --- a/BaseTools/Source/C/GenFw/Elf64Convert.c +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c @@ -1044,6 +1044,19 @@ WriteSections64 ( /* fall through */ case R_AARCH64_ADR_PREL_PG_HI21: + // + // In order to handle Cortex-A53 erratum #843419, the LD linker may + // convert ADRP instructions into ADR instructions, but without + // updating the static relocation type, and so we may end up here + // while the instruction in question is actually ADR. So let's + // just disregard it: the section offset check we apply below to + // ADR instructions will trigger for its R_AARCH64_xxx_ABS_LO12_NC + // companion instruction as well, so it is safe to omit it here. + // + if ((*(UINT32 *)Targ & BIT31) == 0) { + break; + } + // // AArch64 PG_H21 relocations are typically paired with ABS_LO12 // relocations, where a PC-relative reference with +/- 4 GB range is -- 2.17.1