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 B19FC2194D3AE for ; Tue, 11 Dec 2018 03:19:49 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id x19so2999065itl.1 for ; Tue, 11 Dec 2018 03:19:49 -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=3gDesK0pg8CqYxYejwC48/XQ59e6hgHw0ma3d0S5Lwk=; b=ckme+0jbvz2ktaS4zJKrX4EzqClpLkqS1TZF4zC05gtSeWapZaj0iiH0HBsl59Hgx2 jo3ZSRIdv9BywQqvxLRdnCd7dJaceNtz8nnMVaSpv6KGISjvo6cM0lxJUkQGBaiywEXq OtcwY80YZDSrM5i5Dx/hnmPsyPVkzGhtvqHXY= 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=3gDesK0pg8CqYxYejwC48/XQ59e6hgHw0ma3d0S5Lwk=; b=BcqALEEbIPapKBNUnnSuqfkuUsku2yfH92x/iaGakQrULGKFmN8gERRe4xWLSbeODb m0hfJFVHGRdJS7goXEED+jnAx0Ho+mPl0RGtehuNA3QywImcdgN4bMzwoDO1Am30cFto 9ppq9U5KfmvIPvc6ur4biXNsarvXZm4zH2EcxF6Z+6JllVXaGlg5/LBECC/+ezUkayx/ KoMEHlhaDJapJ/yGPdLOmTT1v/n6dnrWUeOQeKyMBv5WkOjksMOGNIU2p5o6Rz+jpc8A gw/z50tVBsv+GX6FNZGSmK4O+9SkNw7NkiMbsyDVj551eghW9qG5syqaza8DLGLIghdb 3SGw== X-Gm-Message-State: AA+aEWZGYkRDf+shXJX3pllV+FnK0qJ6hZWlRVT1hAU2j8qRa0zpU/Lh krh7mt6eT3oB0XwEmbTYfSFsUx25VUZHTiG0MXWUew== X-Google-Smtp-Source: AFSGD/VPyPDrtvcDtgnOkL8Nim0OjVWKn/bbOo1j1I4l5TOO6B/ViQeSOhAzffx+6MYQVJeBEU9pgBfvObQh/Akjryk= X-Received: by 2002:a02:734b:: with SMTP id a11mr14078472jae.62.1544527188340; Tue, 11 Dec 2018 03:19:48 -0800 (PST) MIME-Version: 1.0 References: <20181211093715.6048-1-ard.biesheuvel@linaro.org> <20181211095352.7bpfscgu3e3ne42m@bivouac.eciton.net> In-Reply-To: <20181211095352.7bpfscgu3e3ne42m@bivouac.eciton.net> From: Ard Biesheuvel Date: Tue, 11 Dec 2018 12:19:37 +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:19:49 -0000 Content-Type: text/plain; charset="UTF-8" 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.