All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <laurent@vivier.eu>
To: qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"Riku Voipio" <riku.voipio@iki.fi>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Laurent Vivier" <laurent@vivier.eu>
Subject: [PULL 02/17] linux-user: Reserve space for brk
Date: Thu, 23 Jan 2020 09:22:12 +0100	[thread overview]
Message-ID: <20200123082227.2037994-3-laurent@vivier.eu> (raw)
In-Reply-To: <20200123082227.2037994-1-laurent@vivier.eu>

From: Richard Henderson <richard.henderson@linaro.org>

With bad luck, we can wind up with no space at all for brk,
which will generally cause the guest malloc to fail.

This bad luck is easier to come by with ET_DYN (PIE) binaries,
where either the stack or the interpreter (ld.so) gets placed
immediately after the main executable.

But there's nothing preventing this same thing from happening
with ET_EXEC (normal) binaries, during probe_guest_base().

In both cases, reserve some extra space via mmap and release
it back to the system after loading the interpreter and
allocating the stack.

The choice of 16MB is somewhat arbitrary.  It's enough for libc
to get going, but without being so large that 32-bit guests or
32-bit hosts are in danger of running out of virtual address space.
It is expected that libc will be able to fall back to mmap arenas
after the limited brk space is exhausted.

Launchpad: https://bugs.launchpad.net/qemu/+bug/1749393
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20200117230245.5040-1-richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
---
 linux-user/elfload.c | 73 +++++++++++++++++++++++++++++++++-----------
 linux-user/qemu.h    |  1 +
 2 files changed, 57 insertions(+), 17 deletions(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 511e4500788b..f3080a16358c 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -10,6 +10,7 @@
 #include "qemu/path.h"
 #include "qemu/queue.h"
 #include "qemu/guest-random.h"
+#include "qemu/units.h"
 
 #ifdef _ARCH_PPC64
 #undef ARCH_DLINFO
@@ -2364,24 +2365,51 @@ static void load_elf_image(const char *image_name, int image_fd,
         }
     }
 
-    load_addr = loaddr;
-    if (ehdr->e_type == ET_DYN) {
-        /* The image indicates that it can be loaded anywhere.  Find a
-           location that can hold the memory space required.  If the
-           image is pre-linked, LOADDR will be non-zero.  Since we do
-           not supply MAP_FIXED here we'll use that address if and
-           only if it remains available.  */
-        load_addr = target_mmap(loaddr, hiaddr - loaddr, PROT_NONE,
-                                MAP_PRIVATE | MAP_ANON | MAP_NORESERVE,
-                                -1, 0);
-        if (load_addr == -1) {
-            goto exit_perror;
+    if (pinterp_name != NULL) {
+        /*
+         * This is the main executable.
+         *
+         * Reserve extra space for brk.
+         * We hold on to this space while placing the interpreter
+         * and the stack, lest they be placed immediately after
+         * the data segment and block allocation from the brk.
+         *
+         * 16MB is chosen as "large enough" without being so large
+         * as to allow the result to not fit with a 32-bit guest on
+         * a 32-bit host.
+         */
+        info->reserve_brk = 16 * MiB;
+        hiaddr += info->reserve_brk;
+
+        if (ehdr->e_type == ET_EXEC) {
+            /*
+             * Make sure that the low address does not conflict with
+             * MMAP_MIN_ADDR or the QEMU application itself.
+             */
+            probe_guest_base(image_name, loaddr, hiaddr);
         }
-    } else if (pinterp_name != NULL) {
-        /* This is the main executable.  Make sure that the low
-           address does not conflict with MMAP_MIN_ADDR or the
-           QEMU application itself.  */
-        probe_guest_base(image_name, loaddr, hiaddr);
+    }
+
+    /*
+     * Reserve address space for all of this.
+     *
+     * In the case of ET_EXEC, we supply MAP_FIXED so that we get
+     * exactly the address range that is required.
+     *
+     * Otherwise this is ET_DYN, and we are searching for a location
+     * that can hold the memory space required.  If the image is
+     * pre-linked, LOADDR will be non-zero, and the kernel should
+     * honor that address if it happens to be free.
+     *
+     * In both cases, we will overwrite pages in this range with mappings
+     * from the executable.
+     */
+    load_addr = target_mmap(loaddr, hiaddr - loaddr, PROT_NONE,
+                            MAP_PRIVATE | MAP_ANON | MAP_NORESERVE |
+                            (ehdr->e_type == ET_EXEC ? MAP_FIXED : 0),
+                            -1, 0);
+    if (load_addr == -1) {
+        goto exit_perror;
     }
     load_bias = load_addr - loaddr;
 
@@ -2860,6 +2888,17 @@ int load_elf_binary(struct linux_binprm *bprm, struct image_info *info)
     bprm->core_dump = &elf_core_dump;
 #endif
 
+    /*
+     * If we reserved extra space for brk, release it now.
+     * The implementation of do_brk in syscalls.c expects to be able
+     * to mmap pages in this space.
+     */
+    if (info->reserve_brk) {
+        abi_ulong start_brk = HOST_PAGE_ALIGN(info->brk);
+        abi_ulong end_brk = HOST_PAGE_ALIGN(info->brk + info->reserve_brk);
+        target_munmap(start_brk, end_brk - start_brk);
+    }
+
     return 0;
 }
 
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index f6f5fe5fbb55..560a68090e14 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -35,6 +35,7 @@ struct image_info {
         abi_ulong       end_data;
         abi_ulong       start_brk;
         abi_ulong       brk;
+        abi_ulong       reserve_brk;
         abi_ulong       start_mmap;
         abi_ulong       start_stack;
         abi_ulong       stack_limit;
-- 
2.24.1



  parent reply	other threads:[~2020-01-23  8:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23  8:22 [PULL 00/17] Linux user for 5.0 patches Laurent Vivier
2020-01-23  8:22 ` [PULL 01/17] linux-user:Fix align mistake when mmap guest space Laurent Vivier
2020-01-23  8:22 ` Laurent Vivier [this message]
2020-01-23  8:22 ` [PULL 03/17] linux-user: Add support for FS_IOC_<GET|SET>VERSION ioctls Laurent Vivier
2020-01-23  8:22 ` [PULL 04/17] linux-user: Add support for FS_IOC32_<GET|SET>FLAGS ioctls Laurent Vivier
2020-01-23  8:22 ` [PULL 05/17] linux-user: Add support for FS_IOC32_<GET|SET>VERSION ioctls Laurent Vivier
2020-01-23  8:22 ` [PULL 06/17] linux-user: Add support for FD<SETEMSGTRESH|SETMAXERRS|GETMAXERRS> ioctls Laurent Vivier
2020-01-23  8:22 ` [PULL 07/17] linux-user: Add support for FDFMT<BEG|TRK|END> ioctls Laurent Vivier
2020-01-23  8:22 ` [PULL 08/17] configure: Detect kcov support and introduce CONFIG_KCOV Laurent Vivier
2020-01-23  8:22 ` [PULL 09/17] linux-user: Add support for KCOV_<ENABLE|DISABLE> ioctls Laurent Vivier
2020-01-23  8:22 ` [PULL 10/17] linux-user: Add support for KCOV_INIT_TRACE ioctl Laurent Vivier
2020-01-23  8:22 ` [PULL 11/17] linux-user: Add support for TYPE_LONG and TYPE_ULONG in do_ioctl() Laurent Vivier
2020-01-23  8:22 ` [PULL 12/17] linux-user: Add support for enabling/disabling RTC features using ioctls Laurent Vivier
2020-01-23  8:22 ` [PULL 13/17] linux-user: Add support for getting/setting RTC time and alarm " Laurent Vivier
2020-01-23  8:22 ` [PULL 14/17] linux-user: Add support for getting/setting RTC periodic interrupt and epoch " Laurent Vivier
2020-01-23  8:22 ` [PULL 15/17] linux-user: Add support for getting/setting RTC wakeup alarm " Laurent Vivier
2020-01-23  8:22 ` [PULL 16/17] linux-user: Add support for getting/setting RTC PLL correction " Laurent Vivier
2020-01-23  8:22 ` [PULL 17/17] linux-user: Add support for read/clear RTC voltage low detector " Laurent Vivier
2020-01-23 15:17 ` [PULL 00/17] Linux user for 5.0 patches Peter Maydell

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=20200123082227.2037994-3-laurent@vivier.eu \
    --to=laurent@vivier.eu \
    --cc=alex.bennee@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=riku.voipio@iki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.