Re: [PATCH RFC] fs/binfmt_elf: fix memory map for PIE applications

[Jiri Kosina]

On Thu, 19 Dec 2013, Timo Teras wrote:

> 5756c000-57570000 rw-p 00000000 00:00 0 
> 57570000-575dd000 r-xp 00000000 00:0f 2039       /lib/libuClibc-0.9.33.2-git.so
> 575dd000-575de000 r--p 0006c000 00:0f 2039       /lib/libuClibc-0.9.33.2-git.so
> 575de000-575df000 rw-p 0006d000 00:0f 2039       /lib/libuClibc-0.9.33.2-git.so
> 575df000-575e5000 rw-p 00000000 00:00 0 
> 575e5000-575f5000 r-xp 00000000 00:0f 2038       /lib/libm-0.9.33.2-git.so
> 575f5000-575f6000 r--p 0000f000 00:0f 2038       /lib/libm-0.9.33.2-git.so
> 575f6000-575f7000 rw-p 00010000 00:0f 2038       /lib/libm-0.9.33.2-git.so
> 575f7000-575fd000 r-xp 00000000 00:0f 2042       /lib/libcrypt-0.9.33.2-git.so
> 575fd000-575fe000 r--p 00005000 00:0f 2042       /lib/libcrypt-0.9.33.2-git.so
> 575fe000-57610000 rw-p 00000000 00:00 0 
> 57611000-57613000 rw-p 00000000 00:00 0 
> 57613000-57614000 r-xp 00000000 00:00 0          [vdso]
> 57614000-5761e000 r-xp 00000000 00:0f 2044       /lib/ld-uClibc-0.9.33.2-git.so
> 5761e000-5761f000 r--p 00009000 00:0f 2044       /lib/ld-uClibc-0.9.33.2-git.so
> 5761f000-57620000 rw-p 0000a000 00:0f 2044       /lib/ld-uClibc-0.9.33.2-git.so
> 57620000-57708000 r-xp 00000000 00:0f 234487046  /root/busybox
> 57708000-5770a000 rw-p 000e8000 00:0f 234487046  /root/busybox
> 5770a000-5770c000 rw-p 00000000 00:00 0          [heap]
> 5ffdf000-60000000 rw-p 00000000 00:00 0          [stack]
> b7570000-b75dd000 r-xp 00000000 00:0f 2039       /lib/libuClibc-0.9.33.2-git.so
> b75e5000-b75f5000 r-xp 00000000 00:0f 2038       /lib/libm-0.9.33.2-git.so
> b75f7000-b75fd000 r-xp 00000000 00:0f 2042       /lib/libcrypt-0.9.33.2-git.so
> b7613000-b7614000 r-xp 00000000 00:00 0          [vdso]
> b7614000-b761e000 r-xp 00000000 00:0f 2044       /lib/ld-uClibc-0.9.33.2-git.so
> b7620000-b7708000 r-xp 00000000 00:0f 234487046  /root/busybox
> 
> As you see, the main executable is mapped 57620000-57708000 and
> 57708000-5770a000. Heap follow immediately after that
> 5770a000-5770c000 followed by anything mmaped after it (stack or some
> other libraries). Heap can grow only up to 5ffdf000 meaning the
> application is limited to 140 megs or so in this instance. This limit
> can go much lower depending how the randomization went. And even 140
> megs is very little for big apps.

Right. And why is that a problem? 

Area marked [heap] is basically just an area reserved for brk() calls. 
There is no guarantee how big this area is going to be, there is always 
going to be some mapping getting in the way, that'll prevent it from 
growing indefinitely, and the userspace allocator will have to switch from 
using brk() to mmap() instead.

Glibc is doing this properly, and any allocator that wants to make sure to 
be able to make use of as much virtual address space as possible has 
either give up on brk() completely, or at least switch from brk() to 
mmap() when brk() reaches first mapping.

So what is the real problem again (i.e. the actual symptoms), please? Is 
it that your userspace memory allocator doesn't use mmap() for allocations 
at all?

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/