sbrk() not working under qemu-user with a PIE-compiled binary?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned | ||
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Medium
|
Christian Ehrhardt |
Bug Description
[Impact]
* The current space reserved can be too small and we can end up
with no space at all for BRK. It can happen to any case, but is
much more likely with the now common PIE binaries.
* Backport the upstream fix which reserves a bit more space while loading
and giving it back after interpreter and stack is loaded.
[Test Plan]
* On x86 run:
sudo apt install -y qemu-user-static docker.io
sudo docker run --rm arm64v8/
...
Running hooks in /etc/ca-
done.
Errors were encountered while processing:
libc-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)
Second test from bug 1928075
$ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64 http://
In the bad case this is failing like
W: Failure trying to run: /sbin/ldconfig
W: See //debootstrap/
And in that log file you'll see the segfault
$ tail -n 2 bullseye-
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
[Where problems could occur]
* Regressions would be around use-cases of linux-user that is
emulation not of a system but of binaries.
Commonly uses for cross-tests and cross-builds so that is the
space to watch for regressions
[Other Info]
* n/a
---
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/
bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated)
bash has its own malloc implementation based on sbrk():
https:/
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:/
You can find the problematic bash binary in that .deb file:
http://
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:/
https:/
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:/
Related branches
- Paride Legovini (community): Approve
- Canonical Server packageset reviewers: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 293 lines (+265/-0)4 files modifieddebian/changelog (+9/-0)
debian/patches/series (+2/-0)
debian/patches/ubuntu/lp-1749393-linux-user-Reserve-space-for-brk.patch (+158/-0)
debian/patches/ubuntu/lp-1929926-target-s390x-Fix-translation-exception-on-illegal-in.patch (+96/-0)
tags: | added: arm linux-user |
Changed in qemu: | |
status: | Fix Committed → Fix Released |
Changed in qemu (Ubuntu): | |
assignee: | Richard Henderson (rth) → Christian Ehrhardt (paelzer) |
description: | updated |
Changed in qemu (Ubuntu Focal): | |
status: | Triaged → In Progress |
assignee: | nobody → Christian Ehrhardt (paelzer) |
Affected by the same bug.
target architecture arm
host architecture amd64
bug message
bash: xmalloc: .././locale.c:****: cannot allocate 2 bytes (0 bytes allocated)