All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Ivan A. Melnikov" <iv@altlinux.org>
Cc: qemu-devel@nongnu.org, Laurent Vivier <laurent@vivier.eu>
Subject: Re: [PATCH] linux-user: Adjust pgd_find_hole_fallback result with guest_loaddr
Date: Fri, 05 Mar 2021 14:03:43 +0000	[thread overview]
Message-ID: <87eegtg05n.fsf@linaro.org> (raw)
In-Reply-To: <20210303094919.x6wnlh6qulx72fz6@titan.localdomain>


Ivan A. Melnikov <iv@altlinux.org> writes:

> While pgd_find_hole_fallback returns the beginning of the
> hole found, pgb_find_hole returns guest_base, which
> is somewhat different as the binary qemu-user is loading
> usually has non-zero load address.
>
> Failing to take this into account leads to random crashes
> if the hole is "just big enough", but not bigger:
> in that case, important mappings (e.g. parts of qemu-user
> itself) may be replaced with the binary it is loading
> (e.g. the guest elf interpreter).
>
> This patch also fixes the return type of pgd_find_hole_fallback:
> it returns -1 if no hole is found, so a signed return type
> should be used.

I don't think it should. For one thing the type is preserved as
uintptr_t all the way up the call chain so just changing it here doesn't
help much. -1 is really just a quick way of saying all bits are set
which is the one "fail" value we check for. The address space is big
enough we could theoretically return a chunk of space that otherwise has
the top bit set.

>
> Downstream issue (in Russian): https://bugzilla.altlinux.org/39141
> Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
> ---
>  linux-user/elfload.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index bab4237e90..acd510532c 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -2205,9 +2205,11 @@ static void pgb_have_guest_base(const char *image_name, abi_ulong guest_loaddr,
>   * /proc/self/map. It can potentially take a very long time as we can
>   * only dumbly iterate up the host address space seeing if the
>   * allocation would work.
> + *
> + * Returns the start addres of the hole found, or -1 if no hole found.
>   */
> -static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk,
> -                                        long align, uintptr_t offset)
> +static intptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk,
> +                                       long align, uintptr_t offset)
>  {
>      uintptr_t base;
>  
> @@ -2235,7 +2237,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk,
>                  munmap((void *) align_start, guest_size);
>                  if (MAP_FIXED_NOREPLACE != 0 ||
>                      mmap_start == (void *) align_start) {
> -                    return (uintptr_t) mmap_start + offset;
> +                    return (intptr_t) mmap_start + offset;
>                  }
>              }
>              base += qemu_host_page_size;
> @@ -2259,7 +2261,8 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size,
>      brk = (uintptr_t)sbrk(0);
>  
>      if (!maps) {
> -        return pgd_find_hole_fallback(guest_size, brk, align, offset);
> +        ret = pgd_find_hole_fallback(guest_size, brk, align, offset);
> +        return (ret > guest_loaddr) ? (ret - guest_loaddr) : -1;

So I think we just want:

    return ret == -1 ? -1 : (ret - guest_loaddr);

do we have a test case that triggers this?

>      }
>  
>      /* The first hole is before the first map entry. */


-- 
Alex Bennée


  reply	other threads:[~2021-03-05 14:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03  9:49 [PATCH] linux-user: Adjust pgd_find_hole_fallback result with guest_loaddr Ivan A. Melnikov
2021-03-05 14:03 ` Alex Bennée [this message]
2021-03-05 15:06   ` Ivan A. Melnikov
2021-03-05 15:39     ` Richard Henderson
2021-03-06  9:33 ` [PATCH v2] " Ivan A. Melnikov
2021-03-09 21:49   ` Laurent Vivier

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=87eegtg05n.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=iv@altlinux.org \
    --cc=laurent@vivier.eu \
    --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 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.