| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20251105011548.GB769905@ax162>
Date: Tue, 4 Nov 2025 18:15:48 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Dimitri John Ledkov <dimitri.ledkov@...gut.co.uk>,
Omar Sandoval <osandov@...ndov.com>
Cc: linux-kbuild@...r.kernel.org, Samir M <samir@...ux.ibm.com>,
linux-kernel@...r.kernel.org,
Madhavan Srinivasan <maddy@...ux.ibm.com>,
linuxppc-dev@...ts.ozlabs.org, stable@...r.kernel.org,
Venkat Rao Bagalkote <venkat88@...ux.ibm.com>,
linux-debuggers@...r.kernel.org, Nicolas Schier <nsc@...nel.org>,
Alexey Gladkov <legion@...nel.org>
Subject: Re: [mainline]Error while running make modules_install command
On Tue, Nov 04, 2025 at 08:35:57PM +0000, Dimitri John Ledkov wrote:
> On Tue, 4 Nov 2025 at 18:12, Omar Sandoval <osandov@...ndov.com> wrote:
> > drgn's CI hit this same failure. FWIW, the commit fixed by this bisected
> > commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in
> > vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux
> > for some configurations, which confused drgn until I added a workaround
> > (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d391a).
> > So there's some funkiness in this area.
Omar, could you provide me with a configuration file that reproduces
this for you? Is there an easy way to check for this situation on the
command line?
> The expectation is that said section is removed from the final binary.
> But the fact that it is present with 0 length, indicates incorrect
> linking. It also now makes sense why on x86/arm it is tripping up
> section alignment.
If I diff the output of 'llvm-readelf -e' for vmlinux.unstripped and
vmlinux when building 'ARCH=arm64 defconfig' using my suggested diff on
top of 6.18-rc4, I do see .modinfo get removed and I am not sure I see
an empty segment as a result?
diff --git a/tmp/.psub.Rg1zsq b/tmp/.psub.nGpcxI
index 2f079cb57f58..dcca71062760 100644
--- a/tmp/.psub.Rg1zsq
+++ b/tmp/.psub.nGpcxI
@@ -10,15 +10,15 @@ ELF Header:
Version: 0x1
Entry point address: 0xffff800080000000
Start of program headers: 64 (bytes into file)
- Start of section headers: 157810560 (bytes into file)
+ Start of section headers: 156417384 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
- Number of program headers: 5
+ Number of program headers: 4
Size of section headers: 64 (bytes)
- Number of section headers: 47
- Section header string table index: 46
-There are 47 section headers, starting at offset 0x967ff80:
+ Number of section headers: 46
+ Section header string table index: 45
+There are 46 section headers, starting at offset 0x952bd68:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
@@ -56,19 +56,18 @@ Section Headers:
[31] .mmuoff.data.read PROGBITS ffff80008270b800 271b800 000008 00 WA 0 0 8
[32] .pecoff_edata_padding PROGBITS ffff80008270b808 271b808 0001f8 00 A 0 0 1
[33] .bss NOBITS ffff80008270c000 271ba00 0ac970 00 WA 0 0 4096
- [34] .debug_aranges PROGBITS 0000000000000000 27d09d0 047550 00 0 0 16
- [35] .debug_info PROGBITS 0000000000000000 2817f20 38fdcf1 00 0 0 1
- [36] .debug_abbrev PROGBITS 0000000000000000 6115c11 4845e1 00 0 0 1
- [37] .debug_line PROGBITS 0000000000000000 659a1f2 1848e28 00 0 0 1
- [38] .debug_frame PROGBITS 0000000000000000 7de3020 3e2858 00 0 0 8
- [39] .debug_str PROGBITS 0000000000000000 81c5878 58f8cc 01 MS 0 0 1
- [40] .debug_line_str PROGBITS 0000000000000000 8755144 057ff7 01 MS 0 0 1
- [41] .debug_rnglists PROGBITS 0000000000000000 87ad13b 4d3fc6 00 0 0 1
- [42] .modinfo PROGBITS ffff8000827d0000 2720000 0b09c8 00 A 0 0 1
- [43] .comment PROGBITS 0000000000000000 8c81101 000012 01 MS 0 0 1
- [44] .symtab SYMTAB 0000000000000000 8c81118 671a60 18 45 250028 8
- [45] .strtab STRTAB 0000000000000000 92f2b78 38d1f3 00 0 0 1
- [46] .shstrtab STRTAB 0000000000000000 967fd6b 000215 00 0 0 1
+ [34] .debug_aranges PROGBITS 0000000000000000 271ba00 047550 00 0 0 16
+ [35] .debug_info PROGBITS 0000000000000000 2762f50 38fdcf1 00 0 0 1
+ [36] .debug_abbrev PROGBITS 0000000000000000 6060c41 4845e1 00 0 0 1
+ [37] .debug_line PROGBITS 0000000000000000 64e5222 1848e28 00 0 0 1
+ [38] .debug_frame PROGBITS 0000000000000000 7d2e050 3e2858 00 0 0 8
+ [39] .debug_str PROGBITS 0000000000000000 81108a8 58f8cc 01 MS 0 0 1
+ [40] .debug_line_str PROGBITS 0000000000000000 86a0174 057ff7 01 MS 0 0 1
+ [41] .debug_rnglists PROGBITS 0000000000000000 86f816b 4d3fc6 00 0 0 1
+ [42] .comment PROGBITS 0000000000000000 8bcc131 000012 01 MS 0 0 1
+ [43] .symtab SYMTAB 0000000000000000 8bcc148 612990 18 44 233806 8
+ [44] .strtab STRTAB 0000000000000000 91dead8 34d07e 00 0 0 1
+ [45] .shstrtab STRTAB 0000000000000000 952bb56 00020c 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
@@ -77,21 +76,19 @@ Key to Flags:
Elf file type is DYN (Shared object file)
Entry point 0xffff800080000000
-There are 5 program headers, starting at offset 64
+There are 4 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0xffff800080000000 0xffff800080000000 0x11cc000 0x11cc000 R E 0x10000
LOAD 0x11e0000 0xffff8000811d0000 0xffff8000811d0000 0x153ba00 0x15e8970 RWE 0x10000
- LOAD 0x2720000 0xffff8000827d0000 0xffff8000827d0000 0x0b09c8 0x0b09c8 R 0x10000
NOTE 0x1e83cf4 0xffff800081e73cf4 0xffff800081e73cf4 0x000054 0x000054 R 0x4
- GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
+ GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8
Section to Segment mapping:
Segment Sections...
00 .head.text .text
01 .rodata .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .hyp.rodata .got .got.plt .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .hyp.data..percpu .hyp.reloc .rela.dyn .relr.dyn .data __bug_table .hyp.data .mmuoff.data.write .mmuoff.data.read .pecoff_edata_padding .bss
- 02 .modinfo
- 03 .notes
- 04
+ 02 .notes
+ 03
None .debug_aranges .debug_info .debug_abbrev .debug_line .debug_frame .debug_str .debug_line_str .debug_rnglists .comment .symtab .strtab .shstrtab
> As it is likely that it is the same underlying issue that such segment
> exists in the first place.
>
> I wonder if the original implementation of moving sections about and
> when/where the builtin module info is kept is not as tidy as it was
> intended to be.
This is entirely possible. It would be helpful to know why exactly this
is happening to be certain.
> I wonder if we should:
> - rollback to the state of how things were before that feature was added
> - keep the production / stripped / installed kernel build as is
> - reshuffle of how modinfo is preserved in the unstripped kernel with
> a bespoke linker script
>
> Such that hopefully we have correct alignment, without any zero length segments.
>
> Or possibly even link / split the built-in module info somewhere else entirely.
>
> As in revert both:
> - d50f21091358b (kbuild: align modinfo section for Secureboot
> Authenticode EDK2 compat, 2025-10-26)
> - 3e86e4d74c049 (kbuild: keep .modinfo section in vmlinux.unstripped,
> 2025-09-18)
>
> And try implementing the keeping of .modinfo section again.
>
> Better structure tests, after linking would be nice to catch such
> issues, because linker scripts are hard and trying to understand how a
> linker script change affects the result.
I think if we cannot figure out these issues by -rc6 timeframe, it may
be worth reverting the entire builtin .modinfo series and trying again
for 6.20 (it will probably be too late for 6.19 at that point) but I
would like to avoid doing that to Alexey if possible. I am not sure the
zero length segment issue is worth an entire back out at this point
alone, as I have proposed a fix for the original issue brought up by
this thread.
Cheers,
Nathan
Powered by blists - more mailing lists