From patchwork Wed Feb 1 11:52:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 93006 Delivered-To: patch@linaro.org Received: by 10.182.3.34 with SMTP id 2csp2279574obz; Wed, 1 Feb 2017 03:52:25 -0800 (PST) X-Received: by 10.84.216.86 with SMTP id f22mr3869657plj.117.1485949945462; Wed, 01 Feb 2017 03:52:25 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w185si14201585pgd.51.2017.02.01.03.52.25; Wed, 01 Feb 2017 03:52:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-efi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751266AbdBALwZ (ORCPT + 2 others); Wed, 1 Feb 2017 06:52:25 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:36390 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751259AbdBALwY (ORCPT ); Wed, 1 Feb 2017 06:52:24 -0500 Received: by mail-wm0-f44.google.com with SMTP id c85so35317622wmi.1 for ; Wed, 01 Feb 2017 03:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=7ejqHzetGz6XIs9ARUCe1ddZ79inTVc3zmZXVx3iIXI=; b=UWHzjZggK2ewW+rEdH7+lqUedOKPibYG5srRWEtzhhmSluqZdbd15H3NJ/foNvIKcD 1W/L28vC52QyQ02DXPeMlIdenrLQpMmjweFDonpAK3/J2+kZLwomTjfbtAxptRUdc0hB J02C8TFwf58pO+TjcIM1RlivchzP7TmuQNFZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=7ejqHzetGz6XIs9ARUCe1ddZ79inTVc3zmZXVx3iIXI=; b=eisI6Qck+IWc7lg4xvY0zfcYfGlj/6i4QJdhKydxkq5THRHQkoywjMNa6NlK2O4Iqu myTEJ5ZRGjV0wO/NFwtc/Ec6F6XYVWomAi9IS9fvww3NqmUxwHjBz8oz+Efh7illwmOE /BdoHCdFw0eRMKxm5LDDHOgZBhQAI4sMcUkQU4HDiQv+4daxy+676ev4f5jo1pgEKPZG joUEbc6qjDfiahjSVHTkh3NrjzhyWfXhK2gDdEteIb+zkJ2iKh6/cnRHkaSkn+6m3vfM ExF/2JmQMuIxdeVRFS0AY1MalV4XfjPYHWKQ6ZsJffP5lhJ+rFgXoqn4WaVkQ+TPEIEF 8ysw== X-Gm-Message-State: AIkVDXI7SVBT4GtwrZQTT427L3lcG4HZNlKFGRgMLb7Rln26wHfcwA1XXqMX2dwxr6wgQgma X-Received: by 10.223.133.164 with SMTP id 33mr2325880wrt.39.1485949942608; Wed, 01 Feb 2017 03:52:22 -0800 (PST) Received: from localhost.localdomain ([105.130.17.13]) by smtp.gmail.com with ESMTPSA id k4sm29139660wmf.22.2017.02.01.03.52.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Feb 2017 03:52:21 -0800 (PST) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, leif.lindholm@linaro.org, matt@codeblueprint.co.uk, mark.rutland@arm.com Cc: linux@armlinux.org.uk, Ard Biesheuvel Subject: [PATCH] efi: arm: remove pointless dummy .reloc section Date: Wed, 1 Feb 2017 11:52:16 +0000 Message-Id: <1485949936-12321-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org The kernel's EFI PE/COFF header contains a dummy .reloc section, and an explanatory comment that claims that this is required for the EFI application loader to accept the Image as a relocatable image (i.e., one that can be loaded at any offset and fixed up in place) This was inherited from the x86 implementation, which has elaborate host tooling to mangle the PE/COFF header post-link time, and which populates the .reloc section with a single dummy base relocation. On ARM, no such tooling exists, and the .reloc section remains empty, and is never even exposed via the BaseRelocationTable directory entry, which is where the PE/COFF loader looks for it. The PE/COFF spec is unclear about relocatable images that do not require any fixups, but the EDK2 implementation, which is the de facto reference for PE/COFF in the UEFI space, clearly does not care, and explicitly mentions (in a comment) that relocatable images with no base relocations are perfectly fine, as long as they don't have the RELOCS_STRIPPED attribute set (which is not the case for our PE/COFF image) So simply remove the .reloc section altogether. Signed-off-by: Ard Biesheuvel --- The same applies to arm64 as well, but let's have the discussion first. arch/arm/boot/compressed/efi-header.S | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S index 9d5dc4fda3c1..3b448ab712c8 100644 --- a/arch/arm/boot/compressed/efi-header.S +++ b/arch/arm/boot/compressed/efi-header.S @@ -42,7 +42,7 @@ pe_header: coff_header: .short 0x01c2 @ ARM or Thumb - .short 2 @ nr_sections + .short 1 @ nr_sections .long 0 @ TimeDateStamp .long 0 @ PointerToSymbolTable .long 1 @ NumberOfSymbols @@ -97,22 +97,6 @@ extra_header_fields: .quad 0 @ BaseRelocationTable section_table: - @ - @ The EFI application loader requires a relocation section - @ because EFI applications must be relocatable. This is a - @ dummy section as far as we are concerned. - @ - .ascii ".reloc\0\0" - .long 0 @ VirtualSize - .long 0 @ VirtualAddress - .long 0 @ SizeOfRawData - .long 0 @ PointerToRawData - .long 0 @ PointerToRelocations - .long 0 @ PointerToLineNumbers - .short 0 @ NumberOfRelocations - .short 0 @ NumberOfLineNumbers - .long 0x42100040 @ Characteristics - .ascii ".text\0\0\0" .long _end - __efi_start @ VirtualSize .long __efi_start @ VirtualAddress