[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D852PY6ICCFD.3OQR71A686Q4Z@posteo.net>
Date: Sat, 01 Mar 2025 16:34:52 +0000
From: "Sertonix" <sertonix@...teo.net>
To: <musl@...ts.openwall.com>, "Dmitry Vyukov" <dvyukov@...gle.com>
Subject: Re: Support for -static-pie relocations
On Sat Mar 1, 2025 at 5:22 PM CET, Rich Felker wrote:
> On Sat, Mar 01, 2025 at 05:10:39PM +0100, Szabolcs Nagy wrote:
>> * Dmitry Vyukov <dvyukov@...gle.com> [2025-03-01 16:08:52 +0100]:
>>
>> > Hello,
>> >
>> > This simple program crashes when compiled with -static-pie:
>> >
>> > #include <stdio.h>
>> > int main() { fprintf(stderr, "Hello\n"); }
>> >
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0x0000000000001170 in ?? ()
>> > (gdb) bt
>> > #0 0x0000000000001170 in ?? ()
>> > #1 0x00007ffff7ffb3b8 in libc_start_init () at src/env/__libc_start_main.c:64
>> > #2 0x00007ffff7ffb3e8 in libc_start_main_stage2 (main=0x7ffff7ffb180
>> > <main>, argc=1, argv=0x7fffffffdc98)
>> > at src/env/__libc_start_main.c:92
>> > #3 0x00007ffff7ffb0b1 in _start ()
>> >
>> > (gdb) up
>> > #1 0x00007ffff7ffb3b8 in libc_start_init () at src/env/__libc_start_main.c:64
>> > 64 (*(void (**)(void))a)();
>> >
>> > (gdb) disass
>> > Dump of assembler code for function libc_start_init:
>> > 0x00007ffff7ffb39b <+0>: push %rbp
>> > 0x00007ffff7ffb39c <+1>: push %rbx
>> > 0x00007ffff7ffb39d <+2>: sub $0x8,%rsp
>> > 0x00007ffff7ffb3a1 <+6>: call 0x7ffff7ffb000 <_init>
>> > 0x00007ffff7ffb3a6 <+11>: lea 0x2a9b(%rip),%rbx # 0x7ffff7ffde48
>> > 0x00007ffff7ffb3ad <+18>: lea 0x2a9c(%rip),%rbp # 0x7ffff7ffde50
>> > 0x00007ffff7ffb3b4 <+25>: jmp 0x7ffff7ffb3bc <libc_start_init+33>
>> > 0x00007ffff7ffb3b6 <+27>: call *(%rbx)
>> > => 0x00007ffff7ffb3b8 <+29>: add $0x8,%rbx
>> > 0x00007ffff7ffb3bc <+33>: cmp %rbp,%rbx
>> > 0x00007ffff7ffb3bf <+36>: jb 0x7ffff7ffb3b6 <libc_start_init+27>
>> > 0x00007ffff7ffb3c1 <+38>: add $0x8,%rsp
>> > 0x00007ffff7ffb3c5 <+42>: pop %rbx
>> > 0x00007ffff7ffb3c6 <+43>: pop %rbp
>> > 0x00007ffff7ffb3c7 <+44>: ret
>> > End of assembler dump.
>> >
>> > (gdb) p /x $rbx
>> > $1 = 0x7ffff7ffde48
>> > (gdb) p /x *(void**)$rbx
>> > $2 = 0x1170
>> >
>> > This 0x1170 is probably a ctor pointer offset that wasn't relocated.
>> >
>> > A fix would probably be calling _dl_relocate_object() somewhere on the
>> > __libc_start_main() path.
>> >
>> > Is there a reason this is not supported? Or merely not implemented yet?
>> > Can't find an issue tracker nor searchable archives for previous
>> > discussions on this...
>> >
>> > Thanks in advance
>>
>> i think this is a disagreement about what dynrelocs may appear in
>> static pie between musl and binutils.
>>
>> it is a linker bug if static pie has non-relative relocs.
>> in this case likely there is a symbolic reloc for the init array
>> entry even though we know the symbol value at link time.
>> check the readelf output. (alternative theory: the relocs are
>> missing: bfd ld had bugs like that before)
>>
>> binutils ld is sloppy on some targets but because glibc handles
>> symbolic relocs it is just an unnecessary runtime symbol lookup
>> there. musl considers this unacceptable linker behaviour: it
>> would require half of the dynlinker static linked into every
>> static pie unnecessarily.
>
> I don't think we've hit that on x86_64, and it was long ago fixed on
> the archs we did hit it on, so I don't think that's what's going on.
>
> But a full readelf -a of the failing binary would quickly reveal if
> that's what happened, and would probaby shed light on whatever else if
> wrong if not that.
>
> Rich
I wasn't able to reproduce the exact same issue but I have seen -static-pie
binaries being broken for arm 32 targets. Which arch are you testing on?
Ref https://gitlab.alpinelinux.org/alpine/aports/-/issues/16942#note_484996
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
