From patchwork Wed Feb 8 11:55:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 9562351 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 A8A566047A for ; Wed, 8 Feb 2017 11:57:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9A14A284C9 for ; Wed, 8 Feb 2017 11:57:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8EE2B284CF; Wed, 8 Feb 2017 11:57:02 +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 9343D284C9 for ; Wed, 8 Feb 2017 11:57:01 +0000 (UTC) Received: (qmail 11467 invoked by uid 550); 8 Feb 2017 11:56:38 -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 9739 invoked from network); 8 Feb 2017 11:56:30 -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=SrLACJRtqeqes8x8zbhltXJF5VJs3kD4d+gHL4SAfIg=; b=IsHNNrdZoUx3LMTpmQRZaxhgiLlvNe/1ueD27be3UjfjKh7EqKykVM4Ryevui9Gt6Z dSHAUcc1h0zdgVfRcE49O5SmFgHrzl92SM623N5vOAVLNlmbWLuKvOtxkJ6b3XfbuKA/ co6P/YsFYRDxvfqZHY1pwdINGY3/ubJQPcBmg= 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=SrLACJRtqeqes8x8zbhltXJF5VJs3kD4d+gHL4SAfIg=; b=sFXBhXtd3TufezsQDbM7HfWSAZkMx/HS8zqyfwcOOJyiOHf8U8tIMe6Ci5b6VXAg5T AGH9vlgRzMNdgu3oHsMhhiN8GkBebkR5h6bfAe3xsx5pR8tRz10W8/gLRAecuEkNWvGL EZ+0v/6CmZs5LTY5AVWysaZhZKR6x2a8du5ibCffubFo3ZBd5+F9Ixxps/MqeH+ZjuXy T+X64T3jpVcBTMnbNGR9ofljeQCr53RCEd4/Fawbz+dtiUVpBmcYS7tQjUugr/PnslI9 jdHWLcKWFaspKBMgkI3S4tv4etC+ddQu6s+ERGttkKudQsemY+6OuQ6Jcf9uXIXi+jTX aEsQ== X-Gm-Message-State: AIkVDXIPaCqlu4mJeva2iU0CjVjz4WjbdWoGeygxuejUoKh5VedoFYjFJkii43OcxIbh+Yi+ X-Received: by 10.223.133.131 with SMTP id 3mr18743211wrt.161.1486554978965; Wed, 08 Feb 2017 03:56:18 -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:39 +0000 Message-Id: <1486554947-3964-7-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 06/14] arm64: 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. Acked-by: Mark Rutland Acked-by: Peter Jones Signed-off-by: Ard Biesheuvel --- arch/arm64/kernel/efi-header.S | 22 +------------------- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/arch/arm64/kernel/efi-header.S b/arch/arm64/kernel/efi-header.S index 515624bbfcd0..8786d58af2df 100644 --- a/arch/arm64/kernel/efi-header.S +++ b/arch/arm64/kernel/efi-header.S @@ -12,7 +12,7 @@ .short 0 coff_header: .short 0xaa64 // AArch64 - .short 2 // nr_sections + .short 1 // nr_sections .long 0 // TimeDateStamp .long 0 // PointerToSymbolTable .long 0 // NumberOfSymbols @@ -71,26 +71,6 @@ extra_header_fields: // Section table 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" - .byte 0 - .byte 0 // end of 0 padding of section name - .long 0 - .long 0 - .long 0 // SizeOfRawData - .long 0 // PointerToRawData - .long 0 // PointerToRelocations - .long 0 // PointerToLineNumbers - .short 0 // NumberOfRelocations - .short 0 // NumberOfLineNumbers - .long 0x42000040 // Characteristics (section flags) - - .ascii ".text" .byte 0 .byte 0