qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?
Date: Thu, 15 Mar 2018 16:17:57 -0000	[thread overview]
Message-ID: <152113067774.3926.2973583726995284822.malone@gac.canonical.com> (raw)
In-Reply-To: 151859702399.9461.6832978283203997178.malonedeb@chaenomeles.canonical.com

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

  parent reply	other threads:[~2018-03-15 16:26 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14  8:30 [Qemu-devel] [Bug 1749393] [NEW] sbrk() not working under qemu-user with a PIE-compiled binary? Raphaël Hertzog
2018-02-14 15:46 ` [Qemu-devel] [Bug 1749393] " Gérard Vidal
2018-03-01 19:15 ` Peter Ogden
2018-03-15 11:39 ` Peter Maydell
2018-03-15 15:27 ` Matthias Klose
2018-03-15 16:17 ` Peter Maydell [this message]
2018-03-15 17:56 ` Peter Ogden
2018-03-22 21:45 ` Launchpad Bug Tracker
2018-04-04 16:16 ` Matthias Klose
2020-01-17 23:52 ` Richard Henderson
2020-03-10  9:07 ` Laurent Vivier
2020-04-30 13:34 ` Laurent Vivier
2020-05-01  6:47 ` Christian Ehrhardt 
2020-06-17  7:52 ` Christian Ehrhardt 
2020-08-01  5:05 ` Launchpad Bug Tracker
2021-04-19 23:03 ` Robie Basak
2021-04-26  9:12 ` Launchpad Bug Tracker
2021-04-26  9:17 ` Christian Ehrhardt 
2021-04-26  9:30 ` Christian Ehrhardt 
2021-05-21  0:53 ` Yasuhiro Horimoto
2021-09-17  4:33 ` Sebastian Unger
2021-09-20  9:58 ` Christian Ehrhardt 
2021-11-30  8:44 ` Christian Ehrhardt 
2021-11-30  9:20 ` Christian Ehrhardt 
2021-11-30  9:25 ` Christian Ehrhardt 
2021-11-30 10:10 ` Christian Ehrhardt 
2021-11-30 19:28 ` Brian Murray
2021-12-01  7:46 ` Christian Ehrhardt 
2021-12-16  7:53 ` Christian Ehrhardt 
2021-12-26 12:21 ` frank
2022-01-03 11:42 ` Christian Ehrhardt 
2022-01-04 17:38 ` Launchpad Bug Tracker
2022-01-04 17:39 ` [Bug 1749393] Update Released Brian Murray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=152113067774.3926.2973583726995284822.malone@gac.canonical.com \
    --to=peter.maydell@linaro.org \
    --cc=1749393@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).