From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::143; helo=mail-it1-x143.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 4615D2119BBF3 for ; Tue, 11 Dec 2018 23:39:08 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id c9so8359962itj.1 for ; Tue, 11 Dec 2018 23:39:08 -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=SZxf1o29KumBRalLpVx1Q6np6bBD9MMpTj7SqXo40pI=; b=bfs49pIT02GsP890K8LNnwmz2Sll+o+CNIncEZoMc6GCkL4u7U+yUyXcx0hTnYvai+ CHP1rzZQ/dCanaFdelOq0jP/ty7zQDoYb9wm27eG5sL9GSB0LivLU4evoOhoMWUaDcO/ po1iCx2ln0uSZG8Im6Xi8EBBhDNc/EBOeTe/I= 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=SZxf1o29KumBRalLpVx1Q6np6bBD9MMpTj7SqXo40pI=; b=idUypndi2pSgKlc2YGDdMIr6xULxgxcy3x2+HHMKBYEKIHQDVdVuL7EpgWht4+6Ril 7oCvF+lIkiEVQWgPgdjRMRLRZwRRkqHkINTks9kew+0btcWJfteFoI/QMqCRp9qHvaYE SbJkVmdkjAF1QhEWmCbw4tL2uGP5ltgAVxRihKj63jb3r2sPWlzMgHXe6U9RA0KJxtOD tvQwL8GAKuNwdc/6pTTDDlAtfwbzIP7s8fHdvBb4J7aaklTka9bhwvN+Fv/GElbU8pJO l9r4G1BJ+QzsT4YP8XNb8ELVQ3nwVI9Wqfw6JZCChE50OGzGJkqcFv9LmbDFZOTGT0c5 WFzg== X-Gm-Message-State: AA+aEWZGl1hk1IWGyW4AROZRojQgDaHgX9eNrJi/2/BTW0R8eLUld7xJ 6QNWDhUKK8rLvuVHCNEmj3TEG/Iwx0QOXkhKq8QosjapQXs= X-Google-Smtp-Source: AFSGD/UeSyE2TeK6r2KSTub9aR2XN4MgpHpf2VIIf4Qq75/K8g0x9u3+kpU9N24lC9wG+g3GIJl1oJWuyKkSb/mpchM= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr5158113itk.71.1544600347391; Tue, 11 Dec 2018 23:39:07 -0800 (PST) MIME-Version: 1.0 References: <20181211093715.6048-1-ard.biesheuvel@linaro.org> <20181211095352.7bpfscgu3e3ne42m@bivouac.eciton.net> <4A89E2EF3DFEDB4C8BFDE51014F606A14E38A25D@SHSMSX104.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E38A56F@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E38A56F@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Wed, 12 Dec 2018 08:38:55 +0100 Message-ID: To: "Gao, Liming" Cc: Leif Lindholm , "edk2-devel@lists.01.org" , Laszlo Ersek , "Feng, Bob C" Subject: Re: [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: Wed, 12 Dec 2018 07:39:08 -0000 Content-Type: text/plain; charset="UTF-8" On Wed, 12 Dec 2018 at 01:24, Gao, Liming wrote: > > That's good. Reviewed-by: Liming Gao > Thanks all Pushed as e07092edca84..0d68ce514b92 > >-----Original Message----- > >From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > >Sent: Tuesday, December 11, 2018 9:46 PM > >To: Gao, Liming > >Cc: Leif Lindholm ; edk2-devel@lists.01.org; Laszlo > >Ersek ; Feng, Bob C > >Subject: Re: [PATCH] BaseTools/GenFw ARM: don't permit > >R_ARM_GOT_PREL relocations > > > >On Tue, 11 Dec 2018 at 14:40, Gao, Liming wrote: > >> > >> Ard: > >> With this change, GenFw will report what error message if ELF image has > >R_ARM_GOT_PREL relocations. > >> > > > >Numerous occurrences of > > > >GenFw: ERROR 3000: Invalid > > WriteSections (): > >/home/ard/build/edk2-workspace/Build/ArmVirtQemuKernel- > >ARM/RELEASE_CLANG38/ARM/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreReloc > >atable/DEBUG/ArmVirtPrePiUniCoreRelocatable.dll > >unsupported ELF EM_ARM relocation 0x60. > > > > > >> > -----Original Message----- > >> > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > >> > Sent: Tuesday, December 11, 2018 7:21 PM > >> > To: Leif Lindholm > >> > Cc: edk2-devel@lists.01.org; Laszlo Ersek ; Feng, > >Bob C ; Gao, Liming > >> > > >> > Subject: Re: [PATCH] BaseTools/GenFw ARM: don't permit > >R_ARM_GOT_PREL relocations > >> > > >> > On Tue, 11 Dec 2018 at 12:19, Ard Biesheuvel > >wrote: > >> > > > >> > > On Tue, 11 Dec 2018 at 10:53, Leif Lindholm > >wrote: > >> > > > > >> > > > On Tue, Dec 11, 2018 at 10:37:15AM +0100, Ard Biesheuvel wrote: > >> > > > > 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 > >> > > > > >> > > > Reviewed-by: Leif Lindholm > >> > > > > >> > > > Ouch. This sounds like the best move for now. But how do we deal > >with > >> > > > builds that actually break? > >> > > > > >> > > > >> > > So the only builds that are breaking due to this are ones where we run > >> > > the linker in PIE mode (which only happens in > >> > > ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf), and using the > >> > > GNU gold linker. The reason we need the -pie option is to force the > >> > > linker to emit dynamic relocations into the binary so it can relocate > >> > > itself. This is necessary because the firmware image may execute from > >> > > a a priori unknown memory offset. > >> > > > >> > > I am playing around with hidden visibility and other tweaks to coerce > >> > > the linker into emitting direct relative references instead of GOT > >> > > based ones, and it is very tedious. The GOLD linker really doesn't > >> > > appear to be set up for bare metal binaries. > >> > > >> > Oh, and on AARCH64 it is even more annoying, given that the relative > >> > GOT references are emitted as ADRP/ADD pairs, which means we have > >the > >> > 4 KB alignment issue as well.