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 qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary?
Status in QEMU:
New
Status in qemu package in Ubuntu:
New
Bug description:
In Debian unstable, we recently switched bash to be a PIE-compiled
binary (for hardening). Unfortunately this resulted in bash being
broken when run under qemu-user (for all target architectures, host
being amd64 for me).
$ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash
bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)
bash has its own malloc implementation based on sbrk():
https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c
When we disable this internal implementation and rely on glibc's
malloc, then everything is fine. But it might be that glibc has a
fallback when sbrk() is not working properly and it might hide the
underlying problem in qemu-user.
This issue has also been reported to the bash upstream author and he
suggested that the issue might be in qemu-user so I'm opening a ticket here.
Here's the discussion with the bash upstream author:
https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080
You can find the problematic bash binary in that .deb file:
http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb
The version of qemu I have been using is 2.11 (Debian package qemu-
user-static version 1:2.11+dfsg-1) but I have had reports that the
problem is reproducible with older versions (back to 2.8 at least).
Here are the related Debian bug reports:
https://bugs.debian.org/889869
https://bugs.debian.org/865599
It's worth noting that bash used to have this problem (when compiled as a PIE
binary) even when run directly but then something got fixed in the kernel and
now the problem only appears when run under qemu-user:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1749393/+subscriptions
