Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170201095212.GC12395@port70.net>
Date: Wed, 1 Feb 2017 10:52:13 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Fix pthread_create on some devices failing to initialize
 guard area

* 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.

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.