[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bash's malloc does not work within qemu-user when compiled with PIE
Re: Bash's malloc does not work within qemu-user when compiled with PIE enabled
Wed, 14 Feb 2018 10:25:17 -0500
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
On 2/14/18 3:38 AM, Raphael Hertzog wrote:
> One thing that I saw in that document is "An interesting fact is that if
> you produce a position independent executable, the starting address
> instead changes to 0x0".
> Isn't it possible that sbrk() returns that pointer to you and you treat
> it as being an error instead of a valid address?
If that were the case, it wouldn't work anywhere when compiled in PIE
mode. One of the things the bash malloc does when it sbrks a chunk of
memory is to add it to a chain of memory blocks of a particular size.
The size and link information is stored as part of the free block data.
If sbrk returned 0x0, an attempt to dereference that pointer would most
likely result in a segmentation fault.
Looking at it the other way, if that were a problem with PIE-enabled
executables in general, it would fail in places besides qemu.
>> The thing about the error message in the ubuntu bug report is that it's
>> literally the first call to xmalloc bash makes at startup: the call to
>> savestring when saving the default locale. You can tell because it reports
>> 0 bytes as having been allocated. sbrk() fails immediately.
> In my tests under qemu-user, I see this:
> bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)
> It's "savestring (shell_name)".
Interesting. set_default_locale() comes before that.
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU address@hidden http://tiswww.cwru.edu/~chet/