From: Kees Cook keescook@chromium.org 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 keescook@chromium.org 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 annotations") 6e0a66d10c5b ("arm64/build: Remove .eh_frame* sections due to unwind tables") d1c0272bc1c0 ("x86/boot/compressed: Remove, discard, or assert for unwanted 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=s53vUELe311VSjxt2_eQd+RGNCf__n+cV+R=PQ_...
And it looks like LTO trips over it too: https://lore.kernel.org/lkml/20201211184633.3213045-3-samitolvanen@google.co...
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..compoundliteral* ... -#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