From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 0854429D82 for ; Tue, 16 Jan 2024 16:21:30 +0100 (CET) Received: (qmail 11644 invoked by uid 550); 16 Jan 2024 15:19:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11610 invoked from network); 16 Jan 2024 15:19:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705418477; x=1706023277; darn=lists.openwall.com; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Wr/leSahJ0RkXVZIfmNMBAs6qmCA8gk/r87qFYKCfvg=; b=bbrRxI1aWrT48us9fdwnsruPvU44sqR6D3pLsmH2BbkJDSOl82plLxR2QjaRk+hvKq 8yFvMCMvFSmMZb5g83NVe6iPObQwyzc3/oVuTc2uzG3Mbc6FI0BP0DZq5yC8BXvToFNC QZ4+W2mV1MEX/FItEtFTs1VQCeWAgEG3VGdFf3gB8Fzli8kkhGn5MUiCujp/+a9XEqEi CflLNIIKzom/Gi03PBgiyWmzOH7DFIbNFZrzU/2k49QAligp9Pgj4o02por3WfV4O7+3 bHFPUpAFdgoqcp+lxmoD/AGW2UbnwIILLP0pmAdrecG5NN/Q698SnLfve50m0iYRR8vj cVzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705418477; x=1706023277; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Wr/leSahJ0RkXVZIfmNMBAs6qmCA8gk/r87qFYKCfvg=; b=KH6v+jriefbUkGM06OpaRCug1YfVyDC2t1SwMQjzbRrIOFnePyCo7FLosFxhNDa+h6 uqiiIvb1tzmy/dDLqF7wqFDJVGKdPfQKkP5g93PXm68kw/VB2xdC9EMB6MslCV/5QdCh 9OL1un2OR7OsBcC6/AHuybbZLXH5zKbhRbMtesz+gwcbS7I4KIyaabtA9jn4jsIlw/ZW sfrhXnyTfgx5iNMoEotjJmTh8uuKiyn77kY4XEO5x1QSDc6JsiTAN+OA7xqcD+W9HWyN qLyMyFqRRgC97KzkomJNBzpsbYfLblxtE9zZx3Y+yIQGk3OalstOrSA2UKJyZ3pGnoRh JKVQ== X-Gm-Message-State: AOJu0YwKv43JwiMM8uhBEqA4IQ+ImS3T2ZSXJQsXQkLg2EZJSAfH8aBT RC07+Eb9jfgQufv0vfIFcHZoHi1uODUFQVoAGnM= X-Google-Smtp-Source: AGHT+IGGzFAVpPOhKVdi/SbVngenq4NB2+baRHpqN1n0Bv7v4K+u2JzsB+7cE6ykFHVX9OAAgNsl49GqhOUloe+pGbI= X-Received: by 2002:a05:6902:2491:b0:dbd:716f:8414 with SMTP id ds17-20020a056902249100b00dbd716f8414mr4752096ybb.94.1705418476800; Tue, 16 Jan 2024 07:21:16 -0800 (PST) MIME-Version: 1.0 References: <20231221222513.799557a1@ncopa-desktop.lan> <20240104144811.GO1427497@port70.net> <20240111170323.GP1427497@port70.net> <20240112185713.GQ1427497@port70.net> <20240115223008.GR1427497@port70.net> In-Reply-To: <20240115223008.GR1427497@port70.net> From: Cody Wetzel Date: Tue, 16 Jan 2024 09:21:05 -0600 Message-ID: To: Cody Wetzel , Natanael Copa , musl@lists.openwall.com, Markus Wichmann Content-Type: multipart/alternative; boundary="00000000000080ce2f060f11ae6a" Subject: Re: [musl] Segmentation fault musl 1.2.4 --00000000000080ce2f060f11ae6a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is the output for the old .... > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-armhf.so.1 > > Elf file type is DYN (Shared object file) > Entry point 0x359cd > There are 6 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x100= 00 > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW 0x100= 00 > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > Section to Segment mapping: > Segment Sections... > 00 .ARM.exidx > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > .rodata .ARM.exidx > 02 .data.rel.ro .dynamic .got .data .bss > 03 .dynamic > 04 > 05 .data.rel.ro .dynamic .got > And the new... / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > Elf file type is DYN (Shared object file) > Entry point 0x362f1 > There are 6 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x100= 0 > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW 0x100= 0 > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > Section to Segment mapping: > Segment Sections... > 00 .ARM.exidx > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > .rodata .ARM.exidx > 02 .data.rel.ro .dynamic .got .data .bss > 03 .dynamic > 04 > 05 .data.rel.ro .dynamic .got I hope that helps. Thanks! Cody On Mon, Jan 15, 2024 at 4:30=E2=80=AFPM Szabolcs Nagy wrot= e: > * Cody Wetzel [2024-01-12 17:10:24 -0600]: > > I did actually find that stackoverflow post and tried spinning up a new > > container but the results don't provide any useful information... > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > > GNU gdb (GDB) 12.1 > > > Copyright (C) 2022 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later < > > > http://gnu.org/licenses/gpl.html> > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. > > > Type "show copying" and "show warranty" for details. > > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > > Type "show configuration" for configuration details. > > > For bug reporting instructions, please see: > > > . > > > Find the GDB manual and other documentation resources online at: > > > . > > > > > > For help, type "help". > > > Type "apropos word" to search for commands related to "word"... > > > Reading symbols from ls... > > > (No debugging symbols found in ls) > > > (gdb) run > > > Starting program: /bin/ls -l /tmp > > > During startup program terminated with signal SIGSEGV, Segmentation > fault. > > > > > so i looked at alpine armv7 binaries and they seem to be built with > 4k page size. > > since the elf files are not possible to map with 32k pages, it is > expected that they crash on exec in the kernel and thus you get no > backtrace. > > i'm not sure why gdb works, unless it's an old gdb binary that's built > with large pagesize support. > > an easy way to verify is to compare proram headers of old and new > binaries like > > readelf -lW /tmp/ld-musl-armhf.so.1 > --=20 Cody Wetzel codyawetzel@gmail.com (402)490-9242 --00000000000080ce2f060f11ae6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is the output for the old
....
/ # /tmp/ld-musl-armhf.so.1 /usr/bin/reade= lf -lW /tmp/ld-musl-armhf.so.1

Elf file type is DYN (Shared object f= ile)
Entry point 0x359cd
There are 6 program headers, starting at off= set 52

Program Headers:
=C2=A0 Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Offset =C2=A0 VirtAddr =C2=A0 PhysAddr =C2=A0 FileSiz MemSiz =C2=A0F= lg Align
=C2=A0 EXIDX =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x07acec 0x0007a= cec 0x0007acec 0x00008 0x00008 R =C2=A0 0x4
=C2=A0 LOAD =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x1= 0000
=C2=A0 LOAD =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x07fd6c 0x0008fd6c = 0x0008fd6c 0x0054a 0x02258 RW =C2=A00x10000
=C2=A0 DYNAMIC =C2=A0 =C2=A0= =C2=A0 =C2=A00x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW =C2=A00x4=C2=A0 GNU_STACK =C2=A0 =C2=A0 =C2=A00x000000 0x00000000 0x00000000 0x000= 00 0x00000 RW =C2=A00x10
=C2=A0 GNU_RELRO =C2=A0 =C2=A0 =C2=A00x07fd6c 0= x0008fd6c 0x0008fd6c 0x00294 0x00294 R =C2=A0 0x1

=C2=A0Section to S= egment mapping:
=C2=A0 Segment Sections...
=C2=A0 =C2=A000 =C2=A0 =C2= =A0 .ARM.exidx
=C2=A0 =C2=A001 =C2=A0 =C2=A0 .hash .gnu.hash .dynsym .d= ynstr .rel.dyn .rel.plt .plt .text .rodata .ARM.exidx
=C2=A0 =C2=A002 = =C2=A0 =C2=A0 .data.rel.ro .dynamic .got= .data .bss
=C2=A0 =C2=A003 =C2=A0 =C2=A0 .dynamic
=C2=A0 =C2=A004 = =C2=A0 =C2=A0
=C2=A0 =C2=A005 =C2=A0 =C2=A0 .data.rel.ro .dynamic .got

And = the new...

/ # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-a= rmhf.so.1

Elf file type is DYN (Shared object file)
Entry point 0= x362f1
There are 6 program headers, starting at offset 52

Program= Headers:
=C2=A0 Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Offset =C2=A0 V= irtAddr =C2=A0 PhysAddr =C2=A0 FileSiz MemSiz =C2=A0Flg Align
=C2=A0 EXI= DX =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x07b81c 0x0007b81c 0x0007b81c 0x00008= 0x00008 R =C2=A0 0x4
=C2=A0 LOAD =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0= 00000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000
=C2=A0 LOAD =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x02= 25c RW =C2=A00x1000
=C2=A0 DYNAMIC =C2=A0 =C2=A0 =C2=A0 =C2=A00x07bebc 0= x0007cebc 0x0007cebc 0x000c0 0x000c0 RW =C2=A00x4
=C2=A0 GNU_STACK =C2= =A0 =C2=A0 =C2=A00x000000 0x00000000 0x00000000 0x00000 0x00000 RW =C2=A00x= 10
=C2=A0 GNU_RELRO =C2=A0 =C2=A0 =C2=A00x07bd74 0x0007cd74 0x0007cd74 0= x0028c 0x0028c R =C2=A0 0x1

=C2=A0Section to Segment mapping:
=C2= =A0 Segment Sections...
=C2=A0 =C2=A000 =C2=A0 =C2=A0 .ARM.exidx
=C2= =A0 =C2=A001 =C2=A0 =C2=A0 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.pl= t .plt .text .rodata .ARM.exidx
=C2=A0 =C2=A002 =C2=A0 =C2=A0 .data.rel.ro .dynamic .got .data .bss
=C2=A0= =C2=A003 =C2=A0 =C2=A0 .dynamic
=C2=A0 =C2=A004 =C2=A0 =C2=A0
=C2= =A0 =C2=A005 =C2=A0 =C2=A0 .data.rel.ro = .dynamic .got

I hope that helps.=C2=A0

Thanks!

Cody

<= div class=3D"gmail_quote">
On Mon, Jan= 15, 2024 at 4:30=E2=80=AFPM Szabolcs Nagy <nsz@port70.net> wrote:
* Cody Wetzel <codyawetzel@gmail.com> [2024-01-12 17:10:24 -0= 600]:
> I did actually find that stackoverflow post and tried spinning up a ne= w
> container but the results don't provide any useful information...<= br> >
> / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp
> > GNU gdb (GDB) 12.1
> > Copyright (C) 2022 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <
> > http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it= .
> > There is NO WARRANTY, to the extent permitted by law.
> > Type "show copying" and "show warranty" for d= etails.
> > This GDB was configured as "armv7-alpine-linux-musleabihf&qu= ot;.
> > Type "show configuration" for configuration details. > > For bug reporting instructions, please see:
> > <https://www.gnu.org/software/gdb/bugs/>.<= br> > > Find the GDB manual and other documentation resources online at:<= br> > >=C2=A0 =C2=A0 =C2=A0<http://www.gnu.org/so= ftware/gdb/documentation/>.
> >
> > For help, type "help".
> > Type "apropos word" to search for commands related to &= quot;word"...
> > Reading symbols from ls...
> > (No debugging symbols found in ls)
> > (gdb) run
> > Starting program: /bin/ls -l /tmp
> > During startup program terminated with signal SIGSEGV, Segmentati= on fault.
> >

so i looked at alpine armv7 binaries and they seem to be built with
4k page size.

since the elf files are not possible to map with 32k pages, it is
expected that they crash on exec in the kernel and thus you get no
backtrace.

i'm not sure why gdb works, unless it's an old gdb binary that'= s built
with large pagesize support.

an easy way to verify is to compare proram headers of old and new
binaries like

readelf -lW /tmp/ld-musl-armhf.so.1


--
Co= dy Wetzel
cod= yawetzel@gmail.com
(402)490-9242
--00000000000080ce2f060f11ae6a--