From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::442; helo=mail-wr1-x442.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 8EB4E2194D3B8 for ; Tue, 11 Dec 2018 01:53:56 -0800 (PST) Received: by mail-wr1-x442.google.com with SMTP id t27so13359394wra.6 for ; Tue, 11 Dec 2018 01:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ujiuCnaLDJlpZSEyqIhJammUzteoda8jNzlcchQh1cU=; b=GoKVH6uOJG6NNjXVQpIjdVCPi0iuki4/eQYI1DzUnzdEMH7nVyReKurpi74Tt3l5Z3 ys1hy0T+OWfQM0p6u21kGAbrNCEwh5WDfiIi1xymDI/sWGGqo3tQdkzIwEertzt/F8Mv iSaiChQxvbZJ9djsXyH+WvwPKLQmpeAVQsg/g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ujiuCnaLDJlpZSEyqIhJammUzteoda8jNzlcchQh1cU=; b=nJ47U2QhVn012M3jAKQoVVND3Y1A+78IDcTNlQJ14TyJeIhycyYYkH0nfjL7ZXiaq5 oG4qNloq4uVwZlTHkXdTzjBdWXKgqjvW4gOZwQKWL2EtMy6REhYo+qGpCx6jEWNRVok5 mS0LEi7ybItY12v9RKSpRth4eRZcKl9c6y74vyb1IrkXIMin+3+hVaqZQDEDmqyPP+ql wzaFlPA7wPRRLRKmlDXGrGvPib1dSjP6rMDfo2Gvri3cvjP0oQjMSDNGr2twqbJ0A6T3 AZFipoFVNilDqRIRULPx+mrto7J5684CMJNSFydLGe+Y/6mDOT4kteBvO7Iy/qwxUT12 lCdg== X-Gm-Message-State: AA+aEWZEcJi+5EaU0GhT2w+N0xsR5uEjCaZr5OMwvYYLIfNci4XrYzNJ YcgNvZy4QxUEwV5F5+hCod546A== X-Google-Smtp-Source: AFSGD/VHYEMFcXW0JpMEyG21LNTN8BJOePEwf7NVgDt/9LbvediyCkmbnVINB3/+uYV4PwKAfL5nKg== X-Received: by 2002:a5d:480d:: with SMTP id l13mr4143739wrq.175.1544522034580; Tue, 11 Dec 2018 01:53:54 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id a17sm13784590wrs.58.2018.12.11.01.53.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Dec 2018 01:53:53 -0800 (PST) Date: Tue, 11 Dec 2018 09:53:52 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: edk2-devel@lists.01.org, lersek@redhat.com, Bob Feng , Liming Gao Message-ID: <20181211095352.7bpfscgu3e3ne42m@bivouac.eciton.net> References: <20181211093715.6048-1-ard.biesheuvel@linaro.org> MIME-Version: 1.0 In-Reply-To: <20181211093715.6048-1-ard.biesheuvel@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) 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 09:53:57 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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? > --- > > Without this patch, CLANG38 builds of ArmVirtQemuKernel-ARM (in LTO mode) > succeed, but the resulting binaries are broken. This is due to the fact that > the PIE linker running in LTO mode insists on emitting GOT based relocations, > while we don't have the code to fix up the contents of the GOT. This change > puts it in line with the AARCH64 build of the same platform/toolchains, > which chokes on GOT based relocations as well. Since the use of the PIE > linker is a peculiarity of ArmVirtQemuKernel/ArmVirtXen, and the fact that > it is impossible to prevent the linker from emitting GOT based relocations, > let's not go out of our way to fix it in the tools, but just drop CLANG38 > support from those platforms. > > BaseTools/Source/C/GenFw/Elf32Convert.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c b/BaseTools/Source/C/GenFw/Elf32Convert.c > index 3d7de6d5c123..23e8065756e6 100644 > --- a/BaseTools/Source/C/GenFw/Elf32Convert.c > +++ b/BaseTools/Source/C/GenFw/Elf32Convert.c > @@ -837,7 +837,6 @@ WriteSections32 ( > case R_ARM_LDC_PC_G0: > case R_ARM_LDC_PC_G1: > case R_ARM_LDC_PC_G2: > - case R_ARM_GOT_PREL: > case R_ARM_THM_JUMP11: > case R_ARM_THM_JUMP8: > case R_ARM_TLS_GD32: > @@ -964,7 +963,6 @@ WriteRelocations32 ( > case R_ARM_LDC_PC_G0: > case R_ARM_LDC_PC_G1: > case R_ARM_LDC_PC_G2: > - case R_ARM_GOT_PREL: > case R_ARM_THM_JUMP11: > case R_ARM_THM_JUMP8: > case R_ARM_TLS_GD32: > -- > 2.19.2 >