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=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 CCD9DC433DF for ; Tue, 23 Jun 2020 14:52:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A281520774 for ; Tue, 23 Jun 2020 14:52:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592923945; bh=N5tTtJIP0Rc3W1tOT9EjsbcmdU+QsA32BbRAKafvgJ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=iVwkRSikRktqbZbegeps5WsxxNPRtkuwD4JCFIGGBe8RxlQ/u+42tie5ZmZD9JE4D W0/VS8IjZNNzOMmaC5CQ3YOUokVTiUmDOPLmHQwq5I+Ae5DReTqgj4e2+I3p5ZtxoQ GgdQUboI48saxTFRZZOFck2V2wJYsMQwULJUApQI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732859AbgFWOwY (ORCPT ); Tue, 23 Jun 2020 10:52:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:36558 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732801AbgFWOwY (ORCPT ); Tue, 23 Jun 2020 10:52:24 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C590020723; Tue, 23 Jun 2020 14:52:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592923943; bh=N5tTtJIP0Rc3W1tOT9EjsbcmdU+QsA32BbRAKafvgJ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z6N/8+dviHqm4Jkv5AoCSrmlP/51Oc0ovRXdYgAujUzo215r0oQeXQQE89ZEt113V NqyVKXNVdr43sbhu9Hv2FljKosgPfoDpLMTXOIYJJGa2E1tF8f/M+kT4pFuIogOj3a ZhzWKZiNwD4kndq6VUr4OSl1hZ2siGOruG1gpAls= Date: Tue, 23 Jun 2020 15:52:18 +0100 From: Will Deacon To: Kees Cook Cc: Catalin Marinas , Mark Rutland , Ard Biesheuvel , Arnd Bergmann , Peter Collingbourne , James Morse , Nick Desaulniers , Nathan Chancellor , clang-built-linux@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] arm64/build: Warn on orphan section placement Message-ID: <20200623145218.GC4336@willie-the-truck> References: <20200622205815.2988115-1-keescook@chromium.org> <20200622205815.2988115-3-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200622205815.2988115-3-keescook@chromium.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 22, 2020 at 01:58:15PM -0700, Kees Cook wrote: > We don't want to depend on the linker's orphan section placement > heuristics as these can vary between linkers, and may change between > versions. All sections need to be explicitly named in the linker > script. > > Explicitly include debug sections when they're present. Add .eh_frame* > to discard as it seems that these are still generated even though > -fno-asynchronous-unwind-tables is being specified. Add .plt and > .data.rel.ro to discards as they are not actually used. Add .got.plt > to the image as it does appear to be mapped near .data. Finally enable > orphan section warnings. Can you elaborate a bit on what .got.plt is being used for, please? I wonder if there's an interaction with an erratum workaround in the linker or something. > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index a0d94d063fa8..3e628983445a 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -29,6 +29,10 @@ LDFLAGS_vmlinux += --fix-cortex-a53-843419 > endif > endif > > +# We never want expected sections to be placed heuristically by the > +# linker. All sections should be explicitly named in the linker script. > +LDFLAGS_vmlinux += --orphan-handling=warn > + > ifeq ($(CONFIG_ARM64_USE_LSE_ATOMICS), y) > ifneq ($(CONFIG_ARM64_LSE_ATOMICS), y) > $(warning LSE atomics not supported by binutils) > diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S > index 5427f502c3a6..c9ecb3b2007d 100644 > --- a/arch/arm64/kernel/vmlinux.lds.S > +++ b/arch/arm64/kernel/vmlinux.lds.S > @@ -94,7 +94,8 @@ SECTIONS > /DISCARD/ : { > *(.interp .dynamic) > *(.dynsym .dynstr .hash .gnu.hash) > - *(.eh_frame) > + *(.plt) *(.data.rel.ro) > + *(.eh_frame) *(.init.eh_frame) Do we need to include .eh_frame_hdr here too? > } > > . = KIMAGE_VADDR + TEXT_OFFSET; > @@ -209,6 +210,7 @@ SECTIONS > _data = .; > _sdata = .; > RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_ALIGN) > + .got.plt : ALIGN(8) { *(.got.plt) } > > /* > * Data written with the MMU off but read with the MMU on requires > @@ -244,6 +246,7 @@ SECTIONS > _end = .; > > STABS_DEBUG > + DWARF_DEBUG I know you didn't add it, but do we _really_ care about stabs debug? Who generates that for arm64? Will 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=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 DDB9EC433E0 for ; Tue, 23 Jun 2020 14:54:16 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A754220723 for ; Tue, 23 Jun 2020 14:54:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yGCzwnNj"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z6N/8+dv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A754220723 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yQjhf3PocftUUEypcu7A8dRmeBWRiiBe1lUkcureKT4=; b=yGCzwnNj6Il1+TKkdhQamKKys eI1ds70v6BRZoQ7/xVHSO6OAZ6t6+oy42Fv8X9tFmZJbD9kk/CXtv6Q4e9MR6+6nPQ63GmzmPymPy TPbKO7QXbANn6Ko98X4QoHqiPf7wsbYHAdQopoD1O1+7v7zxrRATSMjHFUhZ3mb4rpcc0ClfReoO8 UQEtQS2AvzskzTTcHLoRBO81hQh/j2caYLSqu/r2MQxcs9Z2giWU4ygKq+YfSSyY793ECmHwGIDcH iIuL5+Ft9FIYmq4pUSHEMI6B7bmXpG3V3Pp6sy7fWzvJeHshqVO3O5dn18xOG0RnBudtZP7hNJss4 McMo0gNqg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnkHk-000213-0O; Tue, 23 Jun 2020 14:52:28 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnkHh-00020U-Af for linux-arm-kernel@lists.infradead.org; Tue, 23 Jun 2020 14:52:26 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C590020723; Tue, 23 Jun 2020 14:52:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592923943; bh=N5tTtJIP0Rc3W1tOT9EjsbcmdU+QsA32BbRAKafvgJ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z6N/8+dviHqm4Jkv5AoCSrmlP/51Oc0ovRXdYgAujUzo215r0oQeXQQE89ZEt113V NqyVKXNVdr43sbhu9Hv2FljKosgPfoDpLMTXOIYJJGa2E1tF8f/M+kT4pFuIogOj3a ZhzWKZiNwD4kndq6VUr4OSl1hZ2siGOruG1gpAls= Date: Tue, 23 Jun 2020 15:52:18 +0100 From: Will Deacon To: Kees Cook Subject: Re: [PATCH v2 2/2] arm64/build: Warn on orphan section placement Message-ID: <20200623145218.GC4336@willie-the-truck> References: <20200622205815.2988115-1-keescook@chromium.org> <20200622205815.2988115-3-keescook@chromium.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200622205815.2988115-3-keescook@chromium.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Arnd Bergmann , Catalin Marinas , Nick Desaulniers , linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com, James Morse , Nathan Chancellor , Peter Collingbourne , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 22, 2020 at 01:58:15PM -0700, Kees Cook wrote: > We don't want to depend on the linker's orphan section placement > heuristics as these can vary between linkers, and may change between > versions. All sections need to be explicitly named in the linker > script. > > Explicitly include debug sections when they're present. Add .eh_frame* > to discard as it seems that these are still generated even though > -fno-asynchronous-unwind-tables is being specified. Add .plt and > .data.rel.ro to discards as they are not actually used. Add .got.plt > to the image as it does appear to be mapped near .data. Finally enable > orphan section warnings. Can you elaborate a bit on what .got.plt is being used for, please? I wonder if there's an interaction with an erratum workaround in the linker or something. > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index a0d94d063fa8..3e628983445a 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -29,6 +29,10 @@ LDFLAGS_vmlinux += --fix-cortex-a53-843419 > endif > endif > > +# We never want expected sections to be placed heuristically by the > +# linker. All sections should be explicitly named in the linker script. > +LDFLAGS_vmlinux += --orphan-handling=warn > + > ifeq ($(CONFIG_ARM64_USE_LSE_ATOMICS), y) > ifneq ($(CONFIG_ARM64_LSE_ATOMICS), y) > $(warning LSE atomics not supported by binutils) > diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S > index 5427f502c3a6..c9ecb3b2007d 100644 > --- a/arch/arm64/kernel/vmlinux.lds.S > +++ b/arch/arm64/kernel/vmlinux.lds.S > @@ -94,7 +94,8 @@ SECTIONS > /DISCARD/ : { > *(.interp .dynamic) > *(.dynsym .dynstr .hash .gnu.hash) > - *(.eh_frame) > + *(.plt) *(.data.rel.ro) > + *(.eh_frame) *(.init.eh_frame) Do we need to include .eh_frame_hdr here too? > } > > . = KIMAGE_VADDR + TEXT_OFFSET; > @@ -209,6 +210,7 @@ SECTIONS > _data = .; > _sdata = .; > RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_ALIGN) > + .got.plt : ALIGN(8) { *(.got.plt) } > > /* > * Data written with the MMU off but read with the MMU on requires > @@ -244,6 +246,7 @@ SECTIONS > _end = .; > > STABS_DEBUG > + DWARF_DEBUG I know you didn't add it, but do we _really_ care about stabs debug? Who generates that for arm64? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel