Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Jan 2024 12:53:33 -0600
From: Cody Wetzel <codyawetzel@...il.com>
To: Cody Wetzel <codyawetzel@...il.com>, Natanael Copa <ncopa@...inelinux.org>, 
	musl@...ts.openwall.com, Markus Wichmann <nullplan@....net>
Subject: Re: Segmentation fault musl 1.2.4

Thank you so much for pointing me in the right direction!

Cody

On Tue, Jan 16, 2024 at 12:29 PM Szabolcs Nagy <nsz@...t70.net> wrote:

> * Cody Wetzel <codyawetzel@...il.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-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
> 0x10000
> > >   LOAD           0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW
> 0x10000
>
> this load segment is 64k aligned.
>
> > >   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
> 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  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.
>
> 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.
>
>

-- 
Cody Wetzel
codyawetzel@...il.com
(402)490-9242

Content of type "text/html" skipped

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.