From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by mx.groups.io with SMTP id smtpd.web10.1823.1573117780920077429 for ; Thu, 07 Nov 2019 01:09:41 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=zvPv8SS+; spf=pass (domain: linaro.org, ip: 209.85.221.68, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wr1-f68.google.com with SMTP id p4so2075669wrm.8 for ; Thu, 07 Nov 2019 01:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IOSX85RMaRA3PiaPsUoQBuY9BhV7/jKH9eTnbxB3YdY=; b=zvPv8SS+P8HGQR1m9qdViHYy/EqfBZP8yHUdh56W7iN241lac9Y9h/ybIsXiHtVOsv 5qC1kfc9IH4fRkYCDDvRw9NnOVDP5LZT/F3eUmuYfZDgjhSQpAS98WZhqvKjsI8yEo42 4BoRmr8qHJWvI12P+yPdQIIkjrv25euOYVntvGdsHqDtge2Udt4Ml56WChMGtpFYWihL q5593iKhp3uk4lpZ+tG9VeICChC2yE33158qz00ePJdoBG1wXfHREU7vbRWIwXkQ4N63 vldHGvZaMvnLnnz0TBU/fcXpo1oFGPc/SQuGOO043fvepTo3qXh/7tX4Jy5kgAS+ZET8 hXWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IOSX85RMaRA3PiaPsUoQBuY9BhV7/jKH9eTnbxB3YdY=; b=La8CmvjeLVY0LN+KxnPSoHlWmB0D80xCdy4Y+SbmZ2kLnTxpg1VlhR29Rvmm7uoVKk nwZz4uxdMzd6QlwoujDl2D3/m9i3/Bf5146bMWgt0mMbaXuij9O5Qbqo+BbG1fgt29Lh 9oSkFw0f/v5+NTudgPDjkeza08AjhcUTC2Sc0oe5/UPlnI9UwT3IdulFkJA88ImPoV7H QFmSvsLJ85ulgub+q1w29KTxh6A2nI/yWpFIJsAvw4EgKfRYuhJIACJNXAANoapOXiQK YadKUdBKHd/7YEQ19JjE50FhLWfOab09aVyHFXFZ0/99E+6eLgin48BlTAN6XUgHhGd2 KczQ== X-Gm-Message-State: APjAAAX47Vtl2/iCcUUgQBwh5nUmLVKaSdL6RAF0U6bvjkxdYcOl+lge Ck7hXg3Jebh+DGwkt3xGKTuRBA9datdVfW27Tg4c8HHSuDo= X-Google-Smtp-Source: APXvYqzRgqZh6h8TmNVipDGUxZkwZ8vyd34WEG76yOcyG5JQN9jiF4/CJeSoSod+svBCPxsQX80Q6mLvXwaeXm4d+jk= X-Received: by 2002:adf:f685:: with SMTP id v5mr1877731wrp.246.1573117778820; Thu, 07 Nov 2019 01:09:38 -0800 (PST) MIME-Version: 1.0 References: <20191107090618.15813-1-ard.biesheuvel@linaro.org> In-Reply-To: <20191107090618.15813-1-ard.biesheuvel@linaro.org> From: "Ard Biesheuvel" Date: Thu, 7 Nov 2019 10:09:27 +0100 Message-ID: Subject: Re: [PATCH 1/1] BaseTools/GenFw AARCH64: disregard ADRP instructions that are patched already To: edk2-devel-groups-io , Leif Lindholm , "Gao, Liming" Cc: "Cohen, Eugene" Content-Type: text/plain; charset="UTF-8" (+ Leif, Liming) On Thu, 7 Nov 2019 at 10:06, Ard Biesheuvel wrote: > > 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 >