All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.