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::d43; helo=mail-io1-xd43.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 955E8211982F6 for ; Tue, 11 Dec 2018 03:21:17 -0800 (PST) Received: by mail-io1-xd43.google.com with SMTP id v10so11445264ios.13 for ; Tue, 11 Dec 2018 03:21:17 -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=LbLm8yimQyHRYU+Gej7ur0YeQQ7TNpxRgmZOaFkqva8=; b=hKyK5RamZmU24xvJklGv0cnx5jHaYLYClafWx+1St4V5C7OfczqhfhjojgkibNZ48x rjota7ICNLM1JTxtCdZ1cGNhDeEi9ks8x95/KWA9hS0beLJLq/J38XskDruN+LIKwjHi 5cGEaCuEJr+lqZWmxBVldsOV/m3QbtF9sTgbo= 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=LbLm8yimQyHRYU+Gej7ur0YeQQ7TNpxRgmZOaFkqva8=; b=symi+w3Lv8T25ylOjsiWPMhurmyNpGtO+mk+nLjCLwt2scHZ4fKx/rMf83ftH7P/Kx rS1KdhK4ayHHxDgyy7v9OeT2YNiGQzziJc62T4B2vErAExx4rMt8xbYn0ORwAwOojgKB 3NDLdddgnjVIzEytasLBk5oeSAV4fJXCdeqC/scU5wW7ucamShJzsFx0kAPg3/alhQZv FUP26al6FjFkT22We96VuC7gl+fiFLY4bUCRxHbwpjktyuKnEt3X2nUY3V7PrHNiMhnt pPK3K+F2DqgljGSwdnDMPsLZt7vVYte/VfcScIg4zXPAhrpHVRaL7x2Ru+gjMmHQDuI9 bXAQ== X-Gm-Message-State: AA+aEWbj6ruedgskaKkHr1/wv0gMZqFNC1NVw+nSTBCaRM51DlODu5Dq xZFymWnpd8Lb3hk34DVs1kgdS0587Y7yEeaBxwWIIQ== X-Google-Smtp-Source: AFSGD/WUv2GxeWvacaliJohklcjZY5SnJLA+ivzPJI5rMgO8pWFIet2u4Klq5GiTarOMC9qIjgVU519YOURJu9UGPig= X-Received: by 2002:a5e:cb42:: with SMTP id h2mr13528538iok.60.1544527276267; Tue, 11 Dec 2018 03:21:16 -0800 (PST) MIME-Version: 1.0 References: <20181211093715.6048-1-ard.biesheuvel@linaro.org> <20181211095352.7bpfscgu3e3ne42m@bivouac.eciton.net> In-Reply-To: From: Ard Biesheuvel Date: Tue, 11 Dec 2018 12:21:04 +0100 Message-ID: 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 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 11:21:17 -0000 Content-Type: text/plain; charset="UTF-8" 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.