There seem to be two parts to this. Firstly, with a big reserved-region,
which is the default for 32-bit-guest-on-64-bit-host, this code in
main.c:
if (reserved_va) {
mmap_next_start = reserved_va;
}
says to start trying for the next mmap address at the top of the
reserved section, which is typically right at the top of the guest's
address space. This means that for a PIE executable we'll try to load it
at a very high address, which then means there's no space above the data
section for the brk segment.
Secondly, for the no-reserved-region case (-R 0, or 64-on-64), we still
fail, but this time because we've chosen to mmap the dynamic interpreter
at an address just above the executable. Again, no space to expand the
data segment and brk fails.
Linux kernel commit a87938b2e246b81 message says something about there
being a guaranteed 128MB "gap" between data segment and stack on x86-64
which we're obviously not honourin; presumbably there's similar
requirements for other archs. (As an aside, is bash really happy with
only having perhaps 128MB of allocatable memory? Otherwise it really
ought to use mmap rather than brk for its allocator.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary?
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1749393/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
