Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <72295197-bf76-b661-dcd6-6d34493a0ac0@gmail.com>
Date: Wed, 1 Feb 2017 10:21:40 -0800
From: Eric Hassold <hassold@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Fix pthread_create on some devices failing to initialize
 guard area


On 2/1/17 1:52 AM, Szabolcs Nagy wrote:
> * Eric Hassold <hassold@...il.com> [2017-01-31 14:44:52 -0800]:
>> On 1/31/17 1:18 PM, Eric Hassold wrote:
>>> Long story short, no odd behavior of the mmap in kernel, but Musl not
>>> supporting correctly non-4k page systems, impacting pthread_create but
>>> probably also malloc and mprotect. Given non-4k page systems are getting
>>> more and more common (on arm and arm64 architectures at least), this
>>> might be an important issue to fix. Should I start new "support for
>>> non-4k page systems" discussion here ?
>>>
>>> Eric
>>>
>> Just removing the "#define PAGE_SIZE 4096" from arch/arm/bits/limits.h makes
>> PAGE_SIZE to be defined by internal/libc.h as libc.page_size which is
>> initialized correctly at runtime, making the correct page size be used all
>> around musl. Since a page size of 4k is no more a valid assumption on
>> arm-linux target, is removing this compile time define a right fix?
> it is ok to remove PAGE_SIZE but i thought arm elf
> binaries would depend on the 4k page size.. making it
> less useful to support other page sizes, but if 32k
> works in practice then i think musl should support it.

Binutils was updated couple years ago to support up to 64KB page size 
and default text alignment to 64kB boundary for armel and match changes 
in kernel:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89

So yes, executables built with older toolchains can't be deployed as is 
on such 32kB pagesize systems, but no issue with with executables built 
with recent  (binutils 2.27 && gcc 5.4) toolchain we are using.

Any further action on my side to proceed? I guess no much value in 
submitting a patch though mail here for such one liner change...

Eric

>
> i guess the boundary of unaligned sections will be
> mapped twice which is not a big issue except may be
> you don't get relro support if the readonly relocs
> are 4k aligned.

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.