From patchwork Wed Feb 8 11:55:44 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 9562361 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id BFD0E6047A for ; Wed, 8 Feb 2017 11:57:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B194C284C9 for ; Wed, 8 Feb 2017 11:57:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A5A41284CF; Wed, 8 Feb 2017 11:57:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id A9D83284C9 for ; Wed, 8 Feb 2017 11:57:40 +0000 (UTC) Received: (qmail 11747 invoked by uid 550); 8 Feb 2017 11:56:45 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 11648 invoked from network); 8 Feb 2017 11:56:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=B9AA5JhlhklbDBxypnaXasxNRovST2QF7QshWwi2npA=; b=R1Ax7ARTHMu2XeV0BQJW75IGdZ3Kpi2HG/g7VVJBix+AqAKZWSlHf2arwyriw6TtdV soDwba/3+SCcenE0OLFMYt/xveLO1i/HytFnj+LiFUJIokzdylQtC/17H2v2rndj2rXl nzukSg+Dl3uLzDFrp+HlcWMga9F16nMghkp+A= 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:in-reply-to :references; bh=B9AA5JhlhklbDBxypnaXasxNRovST2QF7QshWwi2npA=; b=F/iFXvoxRsSuU+A8jrMAyz5i2iD+PmR7acdMEtsYT7Fq6WmFpSTna+xn10NDCUgIVj fYGN+YatVSgmDtWooUFzubwlfmFAeI8mL2QdwVGXbFjFQw3RO00z+F2aZLL3/DihW7m6 GAUIjsrZBmrm/d0/QRWKb35GUZ909O8TbhE1XSRkdiMZf79TOX8IhO07iG5a2NbGWewr H/jufEtcej83EJs4seQZdcXPZNiwGd7/5qRx868PnpIiV32SvN6+ut0edjS+9+rXDlD/ nomPSVXMe4Djq/8BGm4eOOFpZpN0+V7mj+cAK7KuP8JWFKTnPgvs8s8VOXGz/SjK9HcU 37Ug== X-Gm-Message-State: AMke39kp5sKygclYYt8F5+/i2e4c7L30OMNFScedGlJyF6f3ruHiFFw4IEYjaWzMnQZBZ8eu X-Received: by 10.28.207.70 with SMTP id f67mr16564500wmg.72.1486554991195; Wed, 08 Feb 2017 03:56:31 -0800 (PST) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, leif.lindholm@linaro.org Cc: catalin.marinas@arm.com, linux@armlinux.org.uk, kernel-hardening@lists.openwall.com, labbott@fedoraproject.org, Ard Biesheuvel Date: Wed, 8 Feb 2017 11:55:44 +0000 Message-Id: <1486554947-3964-12-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1486554947-3964-1-git-send-email-ard.biesheuvel@linaro.org> References: <1486554947-3964-1-git-send-email-ard.biesheuvel@linaro.org> Subject: [kernel-hardening] [PATCH v2 11/14] arm: efi: remove pointless dummy .reloc section X-Virus-Scanned: ClamAV using ClamSMTP 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 --- arch/arm/boot/compressed/efi-header.S | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S index 50eff3bbc57c..5873fc2b5f9a 100644 --- a/arch/arm/boot/compressed/efi-header.S +++ b/arch/arm/boot/compressed/efi-header.S @@ -40,7 +40,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 0 @ NumberOfSymbols @@ -95,22 +95,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 0x42000040 @ Characteristics - .ascii ".text\0\0\0" .long _end - __efi_start @ VirtualSize .long __efi_start @ VirtualAddress