From: Tom Saeger <tom.saeger@oracle.com>
To: stable@vger.kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: [PATCH 5.15 5.10 5.4 0/1] arm64: fix Build ID if CONFIG_MODVERSIONS
Date: Tue, 6 Dec 2022 13:43:07 -0700 [thread overview]
Message-ID: <cover.1670358255.git.tom.saeger@oracle.com> (raw)
Hi Greg,
Our internal rpm build for aarch64 started failing after merging
v5.15.60. The build actually succeeds, but packaging failed due to tools
which extract the Build ID from vmlinux.
Expected:
readelf -n vmlinux
Displaying notes found in: .notes
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: ae5803ded69a15fb0a75905ec226a76cc1823d22
Linux 0x00000004 func
description data: 00 00 00 00
Linux 0x00000001 OPEN
description data: 00
Actual (post v5.15.60 merge):
readelf -n vmlinux
<no output>
Digging deeper...
Expected:
readelf --headers vmlinux | sed -ne '/Program Header/,$p'
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000010000 0xffff800008000000 0xffff800008000000
0x0000000002012a00 0x000000000208f724 RWE 0x10000
NOTE 0x0000000001705948 0xffff8000096f5948 0xffff8000096f5948
0x0000000000000054 0x0000000000000054 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
Section to Segment mapping:
Segment Sections...
00 .head.text .text .got.plt .rodata .pci_fixup __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param __modver __ex_table .notes .hyp.rodata .init.text .exit.text .altinstructions .init.data .data..percpu .hyp.data..percpu .hyp.reloc .rela.dyn .data __bug_table .mmuoff.data.write .mmuoff.data.read .pecoff_edata_padding .bss
01 .notes
02
Actual:
readelf --headers vmlinux | sed -ne '/Program Header/,$p'
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000010000 0xffff800008000000 0xffff800008000000
0x0000000002012a00 0x000000000208f724 RWE 0x10000
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
Section to Segment mapping:
Segment Sections...
00 .head.text .text .got.plt .rodata .pci_fixup __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param __modver __ex_table .notes .hyp.rodata .init.text .exit.text .altinstructions .init.data .data..percpu .hyp.data..percpu .hyp.reloc .rela.dyn .data __bug_table .mmuoff.data.write .mmuoff.data.read .pecoff_edata_padding .bss
01
readelf -n fails since NOTE segment is missing from vmlinux.
Why?
5.15 Commit: 4c7ee827da2c ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
surfaced this issue.
1. Reverting this patch fixed this issue.
2. Removing all .note.GNU-stack sections in cmd_modversions_S also worked:
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 17aa8ef2d52a..b95cfbb43cee 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -379,6 +379,8 @@ cmd_modversions_S = \
if $(OBJDUMP) -h $@ | grep -q __ksymtab; then \
$(call cmd_gensymtypes_S,$(KBUILD_SYMTYPES),$(@:.o=.symtypes)) \
> $(@D)/.tmp_$(@F:.o=.ver); \
+ echo "SECTIONS { /DISCARD/ : { *(.note.GNU-stack) }}" \
+ >> $(@D)/.tmp_$(@F:.o=.ver); \
\
$(LD) $(KBUILD_LDFLAGS) -r -o $(@D)/.tmp_$(@F) $@ \
-T $(@D)/.tmp_$(@F:.o=.ver); \
3. But the simplest fix I found was to remove -z noexecstack just for
head.S (this patch).
This issue exists, in my testing of arm64 builds, for stable versions
5.15.30+, 5.10.136+, and 5.4.210+
and reproduces with every attempted combination of gcc{11,12}
ld{2.36,2.37,2.38,2.39}.
It can also be reproduced upstream by cherry-picking 0d362be5b142 on-top until
7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS")
which was part of merge
df202b452fe6 ("Merge tag 'kbuild-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild")
It seems kernels prior to v5.4 and 5.19+ use differing KBUILD rules
(with CONFIG_MODVERSIONS=y) for linking components of vmlinux, and in my
testing these other versions did not encounter this issue.
Other architectures besides arm64 might also have similar bug/feature of ld.
Though, x86_64 v5.15.60 worked as expected, so no further experiments
were performed for x86_64.
arm64 repro test:
make ARCH=arm64 mrproper
cp arch/arm64/configs/defconfig ".config"
scripts/config -e MODVERSIONS
make ARCH=arm64 olddefconfig
make ARCH=arm64 -j16 vmlinux
readelf -n vmlinux | grep -F "Build ID:"
Please consider applying for 5.15, 5.10, and 5.4.
Regards,
--Tom
Tom Saeger (1):
arm64: fix Build ID if CONFIG_MODVERSIONS
arch/arm64/kernel/Makefile | 5 +++++
1 file changed, 5 insertions(+)
base-commit: e4a7232c917cd1b56d5b4fa9d7a23e3eabfecba0
--
2.38.1
next reply other threads:[~2022-12-06 20:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 20:43 Tom Saeger [this message]
2022-12-06 20:43 ` [PATCH 5.15 5.10 5.4 1/1] arm64: fix Build ID if CONFIG_MODVERSIONS Tom Saeger
2022-12-08 20:34 ` Greg Kroah-Hartman
2022-12-08 23:31 ` Tom Saeger
2022-12-09 6:50 ` Greg Kroah-Hartman
2022-12-09 17:58 ` Nick Desaulniers
2022-12-09 19:57 ` Tom Saeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1670358255.git.tom.saeger@oracle.com \
--to=tom.saeger@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).