From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3A4FC11D0C for ; Thu, 20 Feb 2020 18:14:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BEBD52467E for ; Thu, 20 Feb 2020 18:14:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582222480; bh=RTCdewSJamGvFckV4P7YoFIgXLzqmB5f6ANXaCpYHr4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=dN40g1UHaHugA8kK0UUfmsjfos2dg4jf+Yv9bW0et+P1JrBBFmfBolM+RgWH7lYi6 184ZXRwx+rvB1DxxPl6/hPQK1GDbsX2Bg/4P3OdCVt5d/HSUhE/J2sWHdscixQKmrk jTVvZQgr/gEAwUgURpUK6GxwhQX7S+KJfitfjIec= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728162AbgBTSOk (ORCPT ); Thu, 20 Feb 2020 13:14:40 -0500 Received: from mail.kernel.org ([198.145.29.99]:47798 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727553AbgBTSOk (ORCPT ); Thu, 20 Feb 2020 13:14:40 -0500 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A073224681 for ; Thu, 20 Feb 2020 18:14:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582222479; bh=RTCdewSJamGvFckV4P7YoFIgXLzqmB5f6ANXaCpYHr4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=MSHqx8bjGEK1n8F3wJchSnpqBcmKyG5ONWUNs2xWiUuhAfT0fALuWzdMimt3gyoVh UU+XvUCAiGiXh5kMuYQGctQoZqGpvoK+JoVmdjJm7+SIFdyapAa8RUlFVstw7dxQ2L GImKzEoYx8ucxacA+R3g9G9zWllMYUifwcY9FKHU= Received: by mail-wr1-f51.google.com with SMTP id m16so5672392wrx.11 for ; Thu, 20 Feb 2020 10:14:39 -0800 (PST) X-Gm-Message-State: APjAAAU9gVF++VW7ZuXvm741D78YMJ89foRE8tZW2fQGCMpyBG8iMxD7 6KUsBqYKbaSQJHfu+1Y02ZvOeY8HTN/bZOd7la+HCw== X-Google-Smtp-Source: APXvYqzXwoexh0Cm2IqjjHwIzVHSPeqhFldJl9NnIIiwtUupNGAGvSXpeExmqjzSKmVgxmi3VITDDqUg0/kIWwHYDPk= X-Received: by 2002:a5d:6404:: with SMTP id z4mr16722520wru.262.1582222478032; Thu, 20 Feb 2020 10:14:38 -0800 (PST) MIME-Version: 1.0 References: <20200220110649.1303-1-ardb@kernel.org> <20200220110649.1303-2-ardb@kernel.org> <20200220172831.GA2417225@rani.riverdale.lan> <20200220180454.GA2436919@rani.riverdale.lan> In-Reply-To: <20200220180454.GA2436919@rani.riverdale.lan> From: Ard Biesheuvel Date: Thu, 20 Feb 2020 19:14:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/3] efi/x86: Use symbolic constants in PE header instead of bare numbers To: Arvind Sankar Cc: linux-efi , Laszlo Ersek , Leif Lindholm , Peter Jones , Matthew Garrett , Alexander Graf , Ilias Apalodimas , Heinrich Schuchardt , Daniel Kiper , James Bottomley Content-Type: text/plain; charset="UTF-8" Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Thu, 20 Feb 2020 at 19:05, Arvind Sankar wrote: > > On Thu, Feb 20, 2020 at 06:32:39PM +0100, Ard Biesheuvel wrote: > > Another thing I wondered was whether we really need the .reloc > > section. We don't have one on ARM, and it works fine with the existing > > EDK2 loader. > > Peter: any idea whether the issue with .reloc you pointed out to me > > the other day still exists in EDK2 today? > > commit 743628e868c5 ("x86, efi stub: Add .reloc section back into > image") says that > Some UEFI firmware will not load a .efi with a .reloc section > with a size of 0. > > Is that the issue you're refering to? It is a bit odd, since we actually > leave base relocation table at a size of zero with an RVA of zero, so it > shouldn't even look at the .reloc section according to the spec. At > least current EKD2 code doesn't seem to -- I think it would even work if > you specify fewer tables than 6 so that the base relocation table is > missing altogether. I can only agree with that, and I have never experienced any issues loading PE/COFF images without .reloc sections on any architecture. But looking at that patch, it seems it only changes the .reloc section's size, it doesn't actually add it back. The .reloc section has been there from the beginning, with a note saying that it is required, which doesn't seem to be the case today, and looking at the history of EDK2, I can't really spot any changes in that regard either.