Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Mar 2016 14:11:03 -0500
From: Rich Felker <>
Subject: Re: Memory management, how to protect some address space.

On Thu, Mar 10, 2016 at 09:02:04PM +0200, John Found wrote:
> On Thu, 10 Mar 2016 11:45:15 -0500
> Rich Felker <> wrote:
> > This is not musl-specific; Linux always does that for 32-bit x86
> > binaries running on a 64-bit kernel. You can either run on a 32-bit
> > kernel or set the ADDR_LIMIT_3GB personality() flag when running your
> > program. Assuming part of the address space is not used is not a
> > portable assumption to make, though.
> > 
> > Rich
> Thanks! The sys_personality is exactly what I needed. I simply was
> not aware of this function. Unfortunately the documentation is very
> poor and when testing it, I have some issues, both with MUSL and
> Linux.
> 1. It seems to be MUSL problem - after setting the personality, the first 
> several memory allocations from MUSL's malloc function still return addresses
> outside the 3GB range. After that it starts to allocate proper addresses. 
> The count of the "bad" allocations depends on the size of the allocated blocks.
> Is it a bug, or I must call some MUSL re-initialization function?
> BTW, this behaviour is not observed with glibc. 
> 2. The stack of the application remains allocated above 3GB space. It seems to be
> Linux issue, but I still will appreciate some help.

The proper way to use personality() is before exec'ing your program.
The stack address and some spare memory that musl re-uses as heap get
assigned at exec time before you can do anything within your program
to prevent that from happening. In theory that could happen with glibc
too; if it doesn't you're just getting lucky.


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.