Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp248096pxu; Thu, 7 Jan 2021 04:03:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJykG/VGRJigT3tE2KahnT5m4x5PtDu22Fte5ESO3yCw6++3M5MmsV7KAKQFyzB8JQTZRvUA X-Received: by 2002:a17:906:234d:: with SMTP id m13mr6175438eja.270.1610021019872; Thu, 07 Jan 2021 04:03:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610021019; cv=none; d=google.com; s=arc-20160816; b=nWQmtxP/fTfTm0RZjKjydQ9A75MDUoft8i2ZrTFf4NXjlPQ+6NBUKysVsT6EVwwvHC swQcW7aayZVibA5Rdfto+zTwuSEpAxx9f2pdTVVaDQBxwhLSfZA8ElIZS5TCK+D4kvjd e9aCCIPZIhvnlSsw9GycU3B5klDUc6Gp3V6RYPQIOULB7FwjWOfN1ky8JQH+lKg8e9Rr U85LFCFrsqUPMyGwejuiNHomOQlfu4ADDPnmTjF59l1N/efEIYzhYsPgzA03W/2IwWsA kECoY0KxY8QE8NfhEmDDC50XmqS+a/j7YWhslAXJrmpc6MMdsBAY+ZrWripYqqU+bniC e5bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:reply-to:cc:from:to :dkim-signature:date; bh=/QpZtUfW8sCY4JlyQE+cRg/152g/kjH3nLFh80d0Hbk=; b=w20+TD2rNt/SFK2OSemxAb8UQSiwxmj2OQPoPZCgMp+QEXuN+bhS2uc8+jKzNHoVgQ qL3g1/d+gKBWBWKk6Hpk/NIrZV5nfh6HYoXhDieNyAELucKKM35XpePtR2fAAIibzedn vKcivBlfly7VmjmEIdngjnBzXKrDOCc207xBT/QuF7AjYhQ0KQwbOoUbWPU4txRviFdZ eU6fBGqkyGN9x5NvMbTsPijHWkQn73DFAfQjwWAgyzRAGOyeZ36vRZTjvMYzpEzVB8dD KE096RjUR4FdZqwA4Tcb8t2pUI3GngOO0ZZC0sy69QLYLnQJ7Pv5LwMcZoLoYZpSDtgV CD4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pm.me header.s=protonmail header.b=Ngatwy64; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=pm.me Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w20si2062740ejc.188.2021.01.07.04.02.54; Thu, 07 Jan 2021 04:03:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@pm.me header.s=protonmail header.b=Ngatwy64; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=pm.me Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726576AbhAGMAE (ORCPT + 99 others); Thu, 7 Jan 2021 07:00:04 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:29860 "EHLO mail-40134.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726073AbhAGMAE (ORCPT ); Thu, 7 Jan 2021 07:00:04 -0500 Date: Thu, 07 Jan 2021 11:59:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail; t=1610020761; bh=/QpZtUfW8sCY4JlyQE+cRg/152g/kjH3nLFh80d0Hbk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Ngatwy647URiYFOHt2f6ts1sFxqi75bAxDr7xnIcvZPgZuOkMvFjU0eJYV52wuChA 46KkuGuhpJOWdXPO24qMOoClJI5Gldx28BrcUawpgP5aN/uHvVjChV+R8GoATIQ584 035sbeP9/VlhUJ+cnJ7r+EXdoXtMwkh3nofFve85s0zp5hi6p+4UBsAEj/hMzPl664 Gv1W9LSRdIKlsOYoqp9xWCZ5LSOcABn1CbRqRSUzqZxHBZEirihfdEpOoTqKk9DvRc wUjnpKugp5AAOqgYJ2hFfcOxfqbIZg7GxMrimwapaM+EN0NnWY9FkPxdj29nCS28Ha DgXM++POOkCSQ== To: Kees Cook From: Alexander Lobakin Cc: Alexander Lobakin , Thomas Bogendoerfer , Nathan Chancellor , Fangrui Song , Jiaxun Yang , Alex Smith , Ralf Baechle , Markos Chandras , linux-mips@vger.kernel.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org, Sami Tolvanen Reply-To: Alexander Lobakin Subject: Re: [PATCH v2 mips-next 2/4] MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS Message-ID: <20210107115855.281681-1-alobakin@pm.me> In-Reply-To: <202101061518.67B9E0205@keescook> References: <20210106200713.31840-1-alobakin@pm.me> <20210106200801.31993-1-alobakin@pm.me> <20210106200801.31993-2-alobakin@pm.me> <202101061400.8F83981AE@keescook> <20210106223606.267756-1-alobakin@pm.me> <202101061518.67B9E0205@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Kees Cook Date: Wed, 6 Jan 2021 15:26:18 -0800 > On Wed, Jan 06, 2021 at 10:36:38PM +0000, Alexander Lobakin wrote: >> From: Kees Cook >> Date: Wed, 6 Jan 2021 14:07:07 -0800 >> >>> On Wed, Jan 06, 2021 at 08:08:19PM +0000, Alexander Lobakin wrote: >>>> Discard GNU attributes at link time as kernel doesn't use it at all. >>>> Solves a dozen of the following ld warnings (one per every file): >>>> >>>> mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes' >>>> from `arch/mips/kernel/head.o' being placed in section >>>> `.gnu.attributes' >>>> mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes' >>>> from `init/main.o' being placed in section `.gnu.attributes' >>>> >>>> Misc: sort DISCARDS section entries alphabetically. >>> >>> Hmm, I wonder what is causing the appearance of .eh_frame? With help I >>> tracked down all the causes of this on x86, arm, and arm64, so that's >>> why it's not in the asm-generic DISCARDS section. I suspect this could >>> be cleaned up for mips too? >> >> I could take a look and hunt it down. Could you please give some refs on >> what were the causes and solutions for the mentioned architectures? > > Sure! Here are the ones I could find again: > > 34b4a5c54c42 ("arm64/kernel: Remove needless Call Frame Information annot= ations") > 6e0a66d10c5b ("arm64/build: Remove .eh_frame* sections due to unwind tabl= es") > d1c0272bc1c0 ("x86/boot/compressed: Remove, discard, or assert for unwant= ed sections") > >>> Similarly for .gnu.attributes. What is generating that? (Or, more >>> specifically, why is it both being generated AND discarded?) >> >> On my setup, GNU Attributes consist of MIPS FP type (soft) and >> (if I'm correct) MIPS GNU Hash tables. > > Ah, right, the soft-float markings sound correct to discard, IIUC. > >> By the way. I've built the kernel with LLVM stack (and found several >> subjects for more patches) and, besides '.got', also got a fistful >> of '.data..compoundliteral*' symbols (drivers/mtd/nand/spi/, >> net/ipv6/ etc). Where should they be placed (rodata, rwdata, ...) >> or they are anomalies of some kind and should be fixed somehow? > > Ah yeah, I've seen this before: > https://lore.kernel.org/lkml/202010051345.2Q0cvqdM-lkp@intel.com/ > https://lore.kernel.org/lkml/CAKwvOd=3Ds53vUELe311VSjxt2_eQd+RGNCf__n+cV+= R=3DPQ_CdXQ@mail.gmail.com/ > > And it looks like LTO trips over it too: > https://lore.kernel.org/lkml/20201211184633.3213045-3-samitolvanen@google= .com/ > > So I think the correct solution is to follow Sami's patch and add it to > vmlinux.lds.h: > > -#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..LPBX* > +#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..L* .data..compoundlit= eral* > ... > -#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* > -#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* > +#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* .rodata..L* > +#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* .bss..compoundliteral* > > Can you include a patch for this in your series? > > Thanks! Thanks for the help! Hope now I caught them all properly in v3. > -- > Kees Cook Al