| 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: <aQtISpMElVm7jQ4y@example.org>
Date: Wed, 5 Nov 2025 13:51:22 +0100
From: Alexey Gladkov <legion@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Dimitri John Ledkov <dimitri.ledkov@...gut.co.uk>,
Omar Sandoval <osandov@...ndov.com>, 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>
Subject: Re: [mainline]Error while running make modules_install command
On Tue, Nov 04, 2025 at 06:15:48PM -0700, Nathan Chancellor wrote:
> 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.
Nathan, if you see that my changes are creating more problems than they
are solving, feel free to revert them.
My changes were based on Masahiro Yamada's patches. I didn't expect his
changes to cause many problems. Before his changes, I tried to use a
different approach. If you think it's worth it, we can return to
discussing it.
https://lore.kernel.org/all/cover.1748335606.git.legion@kernel.org/
--
Rgrds, legion
Powered by blists - more mailing lists