Memory management, how to protect some address space.

Memory management, how to protect some address space.

[John Found]

I am using 32bit MUSL for some of my projects, together with SQLite library compiled with MUSL as well.

While running on 64 bit Linux, it sometimes allocates memory on addresses above 0xc0000000. 
But in my application this area (up to the end of the 4GB addressing space) is reserved for special purposes and should never be allocated.

How to make MUSL to work this way?
Should I recompile MUSL (other libraries) with such option or maybe there is some run-time way to make the same thing?

Best Regards.

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found <johnfound@asm32.info>

Re: Memory management, how to protect some address space.

[Rich Felker]

On Thu, Mar 10, 2016 at 10:22:52AM +0200, John Found wrote:
> I am using 32bit MUSL for some of my projects, together with SQLite library compiled with MUSL as well.
> 
> While running on 64 bit Linux, it sometimes allocates memory on addresses above 0xc0000000. 
> But in my application this area (up to the end of the 4GB addressing space) is reserved for special purposes and should never be allocated.
> 
> How to make MUSL to work this way?
> Should I recompile MUSL (other libraries) with such option or maybe there is some run-time way to make the same thing?

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

Re: Memory management, how to protect some address space.

[John Found]

On Thu, 10 Mar 2016 11:45:15 -0500
Rich Felker <dalias@libc.org> 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.

Best Regards

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found <johnfound@asm32.info>

Re: Memory management, how to protect some address space.

[Rich Felker]

On Thu, Mar 10, 2016 at 09:02:04PM +0200, John Found wrote:
> On Thu, 10 Mar 2016 11:45:15 -0500
> Rich Felker <dalias@libc.org> 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.

Rich

Re: Memory management, how to protect some address space.

[John Found]

On Thu, 10 Mar 2016 14:11:03 -0500
Rich Felker <dalias@libc.org> wrote:

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

Hm, isn't it paragraph 22? sys_personality changes the personality of the calling process.
How to call it *before* executing program???

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found <johnfound@asm32.info>

Re: Memory management, how to protect some address space.

[Tomasz Sterna]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

W dniu 10.03.2016, czw o godzinie 21∶23 +0200, użytkownik John Found
napisał:
> Hm, isn't it paragraph 22? sys_personality changes the personality of
> the calling process.
> How to call it *before* executing program???

Either using a wrapper binary, or
right at the beginning check current personality
with personality(0xffffffff) and if it is not what you wanted set
required personality and exec(3) your binary again in the same process
space.


-- 
 /o__ 
(_<^' Beam me up, Scotty! It ate my phaser!


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Memory management, how to protect some address space.

[Rich Felker]

On Thu, Mar 10, 2016 at 09:23:02PM +0200, John Found wrote:
> On Thu, 10 Mar 2016 14:11:03 -0500
> Rich Felker <dalias@libc.org> wrote:
> 
> > 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.
> > 
> > Rich
> 
> Hm, isn't it paragraph 22? sys_personality changes the personality
> of the calling process.
> How to call it *before* executing program???

exec does not make a new process; it replaces the program running in
the current process with a new one. There's actually a command line
too (I forget the name) to run a program with a particular personality
that calls personality() before execve().

Rich

Re: Memory management, how to protect some address space.

[Bryan Hundven]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]


> On Mar 10, 2016, at 12:20 PM, Rich Felker <dalias@libc.org> wrote:
> 
> On Thu, Mar 10, 2016 at 09:23:02PM +0200, John Found wrote:
>> On Thu, 10 Mar 2016 14:11:03 -0500
>> Rich Felker <dalias@libc.org> wrote:
>> 
>>> 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.
>>> 
>>> Rich
>> 
>> Hm, isn't it paragraph 22? sys_personality changes the personality
>> of the calling process.
>> How to call it *before* executing program???
> 
> exec does not make a new process; it replaces the program running in
> the current process with a new one. There's actually a command line
> too (I forget the name) to run a program with a particular personality
> that calls personality() before execve().
> 
> Rich

iirc: setarch

-Bryan

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: Memory management, how to protect some address space.

[Alexander Monakov]

On Thu, 10 Mar 2016, Rich Felker wrote:
> exec does not make a new process; it replaces the program running in
> the current process with a new one. There's actually a command line
> too (I forget the name) to run a program with a particular personality
> that calls personality() before execve().

setarch

It has handy shortcuts like linux32 for switching to a 32-bit uname
personality; in this case you'd use setarch --3gb or just setarch -3.

Alexander

Re: Memory management, how to protect some address space.

[John Found]

On Thu, 10 Mar 2016 15:20:50 -0500
Rich Felker <dalias@libc.org> wrote:

> On Thu, Mar 10, 2016 at 09:23:02PM +0200, John Found wrote:
> > On Thu, 10 Mar 2016 14:11:03 -0500
> > Rich Felker <dalias@libc.org> wrote:
> > 
> > > 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.
> > > 
> > > Rich
> > 
> > Hm, isn't it paragraph 22? sys_personality changes the personality
> > of the calling process.
> > How to call it *before* executing program???
> 
> exec does not make a new process; it replaces the program running in
> the current process with a new one. There's actually a command line
> too (I forget the name) to run a program with a particular personality
> that calls personality() before execve().
> 
> Rich

Yes, indeed, execve is what I needed. Thanks!

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found <johnfound@asm32.info>