qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] linux-user/elfload: do not assume MAP_FIXED_NOREPLACE kernel


From: Vincent Fazio
Subject: Re: [PATCH] linux-user/elfload: do not assume MAP_FIXED_NOREPLACE kernel support
Date: Sun, 14 Feb 2021 08:20:14 -0600

On Sun, Feb 14, 2021 at 6:50 AM Laurent Vivier <laurent@vivier.eu> wrote:
>
> Le 14/02/2021 à 12:24, Alex Bennée a écrit :
> >
> > Vincent Fazio <vfazio@xes-inc.com> writes:
> >
> >> From: Vincent Fazio <vfazio@gmail.com>
> >>
> >> Previously, pgd_find_hole_fallback assumed that if the build host's libc
> >> had MAP_FIXED_NOREPLACE defined that the address returned by mmap would
> >> match the requested address. This is not a safe assumption for Linux
> >> kernels prior to 4.17
> >
> > It doesn't as we have in osdep.h:
> >
> >   #ifndef MAP_FIXED_NOREPLACE
> >   #define MAP_FIXED_NOREPLACE 0
> >   #endif
> >
> > which is to say to assume if MAP_FIXED_NOREPLACE is defined the kernel
> > should have given us what we want otherwise we do the check.
>
>
> But what is the purpose of the "if (MAP_FIXED_NOREPLACE != 0 ||"?
> Can't we rely only on "mmap_start == (void *) align_start"?
>
> Thanks,
> Laurent
>

I think we have to rely on address matching. The problem is
specifically when MAP_FIXED_NOREPLACE is defined and is passed to mmap
but the running kernel doesn't know what to do with the flag so
returns a value that is not what was hinted at. Previously the code
assumed that if MAP_FIXED_NOREPLACE was defined that the returned
address would match, but that isn't always the case if the kernel
doesn't have support for the flag. The 4.4, 4.9 and 4.14 LTS kernels
are still in use and could run into this problem.

-Vincent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]