[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] linux-user/elfload: do not assume MAP_FIXED_NOREPLACE kernel
Re: [PATCH] linux-user/elfload: do not assume MAP_FIXED_NOREPLACE kernel support
Mon, 15 Feb 2021 09:52:26 +0000
mu4e 1.5.8; emacs 28.0.50
Vincent Fazio <email@example.com> writes:
> On Sun, Feb 14, 2021 at 6:50 AM Laurent Vivier <firstname.lastname@example.org> wrote:
>> Le 14/02/2021 à 12:24, Alex Bennée a écrit :
>> > Vincent Fazio <email@example.com> writes:
>> >> From: Vincent Fazio <firstname.lastname@example.org>
>> >> 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"?
> 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.
Ahh right so I think this is a case of binaries being built on a
different platform than kernel they are running on. In which case the
flag would be defined but the underlying kernel fails to identify it. Is
this a container like case by any chance?
If I'd read the man page closer:
Note that older kernels which do not recognize the
MAP_FIXED_NOREPLACE flag will typically (upon detecting a colli‐
sion with a preexisting mapping) fall back to a "non-MAP_FIXED"
type of behavior: they will return an address that is different
from the requested address. Therefore, backward-compatible
software should check the returned address against the requested
so yes we should avoid short circuiting the return address check.
Reviewed-by: Alex Bennée <email@example.com>