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 C1B1A20930 for ; Tue, 16 Jan 2024 19:53:58 +0100 (CET) Received: (qmail 22400 invoked by uid 550); 16 Jan 2024 18:52:08 -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 22355 invoked from network); 16 Jan 2024 18:52:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705431225; x=1706036025; 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=ZkKESendumdz0FoSWbAmzIIxTW28nRXCthNYdeesJy8=; b=P2w3dkcM1r+43kwdCktr3unCpNnSNwI7Pi4Goj1KGGV4Pf62Jqk5L9/yVLVmv3Dh35 whZ2snhgCFu3dGXBsFBojWIjMItgvxGugduTZk9ICZWYyqEij5qUp10o/5WnZqboiqWc hwy3uJgy6nMnJ/DyW1fVci2Bs3JVUdYjOIKxXFV5xty5v98/9BPX1xJyDAhuPdNiMrDY yu9TeKSszaYTje65cMKXjKY9Jm0VCGvSgxEPld44YvcVy5Uobtl6v0Lfr27MkBf+NDeC mpT5ZO8N1rW39/QLoYQ81LyaUaOaQ+CWG6y6TN4tXlHEdlvZq60aKuSPuU09kHmuz9pT w/vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705431225; x=1706036025; 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=ZkKESendumdz0FoSWbAmzIIxTW28nRXCthNYdeesJy8=; b=benXbOCTDkqE9gTLI/LZQoLddKfRfFzcwMRe9U1W2mFmVO4dr8Ak+8yVDJuxcBnbj9 dWDrI3multOinX/lReKot6+QdyhfWaS7cnCOKTxnuDlH/wSq9LtDTPrCFKlN7v7h8Ha0 h+yFHZvu7XexKmLXRtJm0dmeIK4tNizjmaYrI7W5N4/eXS8jXKELwT5OxHhkqOrizD1k VjZyFBPJU5UR0uoSL7qVbTVklxuqFs1phZvespFGzm2qrinIrero6RSfV+OnLM/M+Ta5 vYaomgLg6KMr7eh/WztT+iHxAGCDh6txv0XJEaRH1wSesnstNB+DN3SXfu04zih9oNyC mAyw== X-Gm-Message-State: AOJu0Yzk+tJ1ikXIW1d9xak0z8tKU83f0XcUFfQmMqSKLbPmoLDm5KG2 PYO9l0vh6FQSIoKi5F5nkcm4cv6CXvMiDLau0Ic= X-Google-Smtp-Source: AGHT+IEeCM+uX3+LoZpUvuKTP9+9/1ntmcJggKTK4x3YexSiWSwDfoOcwITZh9O5Zo4eWXGvlCgJMYTs7XOOA73qllc= X-Received: by 2002:a05:6902:2782:b0:d9a:6669:68ce with SMTP id eb2-20020a056902278200b00d9a666968cemr4549813ybb.32.1705431225016; Tue, 16 Jan 2024 10:53:45 -0800 (PST) MIME-Version: 1.0 References: <20240104144811.GO1427497@port70.net> <20240111170323.GP1427497@port70.net> <20240112185713.GQ1427497@port70.net> <20240115223008.GR1427497@port70.net> <20240116182918.GS1427497@port70.net> In-Reply-To: <20240116182918.GS1427497@port70.net> From: Cody Wetzel Date: Tue, 16 Jan 2024 12:53:33 -0600 Message-ID: To: Cody Wetzel , Natanael Copa , musl@lists.openwall.com, Markus Wichmann Content-Type: multipart/alternative; boundary="0000000000005b2531060f14a665" Subject: Re: [musl] Segmentation fault musl 1.2.4 --0000000000005b2531060f14a665 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you so much for pointing me in the right direction! Cody On Tue, Jan 16, 2024 at 12:29=E2=80=AFPM Szabolcs Nagy wro= te: > * Cody Wetzel [2024-01-16 09:21:05 -0600]: > > 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 0= x4 > > > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E > 0x10000 > > > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW > 0x10000 > > this load segment is 64k aligned. > > > > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0= x4 > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW > 0x10 > > > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0= x1 > > > > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .ARM.exidx > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .tex= t > > > .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 0= x4 > > > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E > 0x1000 > > > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW > 0x1000 > > this load segment is 4k aligned and offset vs addr is not congruent > modulo 64k, or 32k, so won't work on systems with such page size. > > > > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0= x4 > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW > 0x10 > > > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0= x1 > > > > > > Section to Segment mapping: > > > Segment Sections... > > > 00 .ARM.exidx > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .tex= t > > > .rodata .ARM.exidx > > > 02 .data.rel.ro .dynamic .got .data .bss > > > 03 .dynamic > > > 04 > > > 05 .data.rel.ro .dynamic .got > > > > > > I hope that helps. > > yes, this is a linking issue, not musl libc. > > alpine linux links binaries for 4k pagesize only. > > arm linkers were updated at some point to create binaries supporting > up to 64k pagesize. i suspect some ppl ran into issues in practice > and decided the larger binaries are not worth it, if they dont work > reliably and forced 4k page size at link time. > > you have to raise an issue with alpine linux, if you think 32k > oage size is useful and reliably supportable. > > --=20 Cody Wetzel codyawetzel@gmail.com (402)490-9242 --0000000000005b2531060f14a665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you so much for pointing me in the right direction!<= div>
Cody

On Tue, Jan 16, 2024 at 12:29=E2=80=AFPM Szab= olcs Nagy <nsz@port70.net> wrot= e:
* Cody Wetzel= <codyawetzel= @gmail.com> [2024-01-16 09:21:05 -0600]:
> Here is the output for the old
> ....
> >
> > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-arm= hf.so.1
> >
> > Elf file type is DYN (Shared object file)
> > Entry point 0x359cd
> > There are 6 program headers, starting at offset 52
> >
> > Program Headers:
> >=C2=A0 =C2=A0Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Offset= =C2=A0 =C2=A0VirtAddr=C2=A0 =C2=A0PhysAddr=C2=A0 =C2=A0FileSiz MemSiz=C2=A0= Flg Align
> >=C2=A0 =C2=A0EXIDX=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x07acec 0x00= 07acec 0x0007acec 0x00008 0x00008 R=C2=A0 =C2=A00x4
> >=C2=A0 =C2=A0LOAD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x000000= 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x10000
> >=C2=A0 =C2=A0LOAD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x07fd6c= 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW=C2=A0 0x10000

this load segment is 64k aligned.

> >=C2=A0 =C2=A0DYNAMIC=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x07febc 0x0008feb= c 0x0008febc 0x000c0 0x000c0 RW=C2=A0 0x4
> >=C2=A0 =C2=A0GNU_STACK=C2=A0 =C2=A0 =C2=A0 0x000000 0x00000000 0x0= 0000000 0x00000 0x00000 RW=C2=A0 0x10
> >=C2=A0 =C2=A0GNU_RELRO=C2=A0 =C2=A0 =C2=A0 0x07fd6c 0x0008fd6c 0x0= 008fd6c 0x00294 0x00294 R=C2=A0 =C2=A00x1
> >
> >=C2=A0 Section to Segment mapping:
> >=C2=A0 =C2=A0Segment Sections...
> >=C2=A0 =C2=A0 00=C2=A0 =C2=A0 =C2=A0.ARM.exidx
> >=C2=A0 =C2=A0 01=C2=A0 =C2=A0 =C2=A0.hash .gnu.hash .dynsym .dynst= r .rel.dyn .rel.plt .plt .text
> > .rodata .ARM.exidx
> >=C2=A0 =C2=A0 02=C2=A0 =C2=A0 =C2=A0.data.rel.ro .dynamic .got .data = .bss
> >=C2=A0 =C2=A0 03=C2=A0 =C2=A0 =C2=A0.dynamic
> >=C2=A0 =C2=A0 04
> >=C2=A0 =C2=A0 05=C2=A0 =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-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:
> >=C2=A0 =C2=A0Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Offset= =C2=A0 =C2=A0VirtAddr=C2=A0 =C2=A0PhysAddr=C2=A0 =C2=A0FileSiz MemSiz=C2=A0= Flg Align
> >=C2=A0 =C2=A0EXIDX=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x07b81c 0x00= 07b81c 0x0007b81c 0x00008 0x00008 R=C2=A0 =C2=A00x4
> >=C2=A0 =C2=A0LOAD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x000000= 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000
> >=C2=A0 =C2=A0LOAD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x07bd74= 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW=C2=A0 0x1000

this load segment is 4k aligned and offset vs addr is not congruent
modulo 64k, or 32k, so won't work on systems with such page size.

> >=C2=A0 =C2=A0DYNAMIC=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x07bebc 0x0007ceb= c 0x0007cebc 0x000c0 0x000c0 RW=C2=A0 0x4
> >=C2=A0 =C2=A0GNU_STACK=C2=A0 =C2=A0 =C2=A0 0x000000 0x00000000 0x0= 0000000 0x00000 0x00000 RW=C2=A0 0x10
> >=C2=A0 =C2=A0GNU_RELRO=C2=A0 =C2=A0 =C2=A0 0x07bd74 0x0007cd74 0x0= 007cd74 0x0028c 0x0028c R=C2=A0 =C2=A00x1
> >
> >=C2=A0 Section to Segment mapping:
> >=C2=A0 =C2=A0Segment Sections...
> >=C2=A0 =C2=A0 00=C2=A0 =C2=A0 =C2=A0.ARM.exidx
> >=C2=A0 =C2=A0 01=C2=A0 =C2=A0 =C2=A0.hash .gnu.hash .dynsym .dynst= r .rel.dyn .rel.plt .plt .text
> > .rodata .ARM.exidx
> >=C2=A0 =C2=A0 02=C2=A0 =C2=A0 =C2=A0.data.rel.ro .dynamic .got .data = .bss
> >=C2=A0 =C2=A0 03=C2=A0 =C2=A0 =C2=A0.dynamic
> >=C2=A0 =C2=A0 04
> >=C2=A0 =C2=A0 05=C2=A0 =C2=A0 =C2=A0.data.rel.ro .dynamic .got
>
>
> I hope that helps.

yes, this is a linking issue, not musl libc.

alpine linux links binaries for 4k pagesize only.

arm linkers were updated at some point to create binaries supporting
up to 64k pagesize.=C2=A0 i suspect some ppl ran into issues in practice and decided the larger binaries are not worth it, if they dont work
reliably and forced 4k page size at link time.

you have to raise an issue with alpine linux, if you think 32k
oage size is useful and reliably supportable.



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