From patchwork Mon Feb 6 16:24:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 9558347 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 6A72E602B1 for ; Mon, 6 Feb 2017 16:25:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5D4D426E54 for ; Mon, 6 Feb 2017 16:25:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5212727F93; Mon, 6 Feb 2017 16:25:43 +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 8480126E54 for ; Mon, 6 Feb 2017 16:25:42 +0000 (UTC) Received: (qmail 27825 invoked by uid 550); 6 Feb 2017 16:25:20 -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 27742 invoked from network); 6 Feb 2017 16:25:19 -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=GFMq8tNrECDa9qdd+zD3lksKOYHWw4jAuda60PNI6/o=; b=GMX1HumsJXxyOlDgxy3HewgKNPaxAJUaB6i6faNNh0/qyOp8S5jTwUZluhrsKGx+TH 16Wde1GKEFdwjfT7b05LPnAgrxHIWno+jOp1ybAeXSMC1eCH1kM99TBffjApUPm9j8TM hlw3VsdTcvFB7nPCYnAWqh6EVYamgMGRXy36I= 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=GFMq8tNrECDa9qdd+zD3lksKOYHWw4jAuda60PNI6/o=; b=YZl1GJF69Y7VDyRBzAq2O+WInbpAAnaj/Ezw5g8vDmgi8+nZ7z+yNi371kEaS0DAzd vv5Ll/OvoDaYIHPuyTzGC6s4FbxtfJUNx8X/CTjB5mE4YnwxsQETlsRyhWYhl44J4Rcj ZJM9XV3MPecm7JcthCAQ+7W4wfVzdWsGU5senO7Gn5imMWSSdJXXZy9rKEvgpPSlb8TA dv/9FR5+c7iEUohpmmyvUbBaxi95et4QgNu5k3E+3D36IZarifTfenAbfF0QX0cm3wx6 rq/Rm/bOVkqEtxMvN7FUBuE+0XAhPqehH12/k6D9mmk/ucxqw+olFMquD//YuaMoIHs6 /4SA== X-Gm-Message-State: AIkVDXKeYJNW141APPCuMPVE2zc54a50GfcSKW7XhTRH31QptkKIfRsugNMUrOxuFYQ3NO5Y X-Received: by 10.223.139.12 with SMTP id n12mr9856118wra.176.1486398308089; Mon, 06 Feb 2017 08:25:08 -0800 (PST) From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org, will.deacon@arm.com, catalin.marinas@arm.com, mark.rutland@arm.com Cc: labbott@fedoraproject.org, kernel-hardening@lists.openwall.com, leif.lindholm@linaro.org, pjones@redhat.com, Ard Biesheuvel Date: Mon, 6 Feb 2017 16:24:33 +0000 Message-Id: <1486398275-3966-6-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1486398275-3966-1-git-send-email-ard.biesheuvel@linaro.org> References: <1486398275-3966-1-git-send-email-ard.biesheuvel@linaro.org> Subject: [kernel-hardening] [PATCH 5/7] 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. Signed-off-by: Ard Biesheuvel Acked-by: Mark Rutland Acked-by: Peter Jones --- 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 74a25c09a1b8..35b11654ecc5 100644 --- a/arch/arm64/kernel/efi-header.S +++ b/arch/arm64/kernel/efi-header.S @@ -37,7 +37,7 @@ pe_header: .short 0 coff_header: .short 0xaa64 // AArch64 - .short 2 // nr_sections + .short 1 // nr_sections .long 0 // TimeDateStamp .long 0 // PointerToSymbolTable .long 1 // NumberOfSymbols @@ -96,26 +96,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 0x42100040 // Characteristics (section flags) - - .ascii ".text" .byte 0 .byte 0