[PATCH 02/13] elf: switch _dl_map_segment() to anonymous mapping

[stsp]

29.03.2023 23:29, Adhemerval Zanella Netto пишет:
> On 29/03/23 15:00, stsp wrote:
>> But its not ignored in glibc, see
>>
>> sysdeps/unix/sysv/linux/x86_64/64/mmap_internal.h
>>
>> Without that flag PREFER_MAP_32BIT_EXEC
>> test fails.
> Because elf/dl-load.h already defines MAP_COPY that handles it, so why
> not use it instead?

Would MAP_COPY be a good choice for
explicitly anonymous mapping? If so -
can change.

>>> So basically it would add another mmap on program loading.  For instance, loading
>>> a simple empty main programs:
>> Yes, that's true.
>> Is this a problem?
>>
>>
> Yes, Linux limits a maximum mmap both per process [1].  This code increase both
> the total mapping requires and runtime cost to setup a new shared library.
>
> [1] https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/sysctl/vm.rst#max_map_count

This talks about the map areas.
I don't think map areas number changed.
Extra syscall - yes. Extra map area - no.
So I don't think my patch is a subject of
the aforementioned system limit.

>>> And it also slight change the mapping, using the same program:
>>>
>>> * Before:
>>>
>>>         0x7ffff7dc2000     0x7ffff7de8000    0x26000        0x0  r--p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7de8000     0x7ffff7f54000   0x16c000    0x26000  r-xp   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7f54000     0x7ffff7faa000    0x56000   0x192000  r--p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7faa000     0x7ffff7fab000     0x1000   0x1e8000  ---p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7fab000     0x7ffff7faf000     0x4000   0x1e8000  r--p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7faf000     0x7ffff7fb1000     0x2000   0x1ec000  rw-p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>
>>> * With this patch:
>>>
>>>         0x7ffff7dc1000     0x7ffff7de7000    0x26000        0x0  r--p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7de7000     0x7ffff7f53000   0x16c000    0x26000  r-xp   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7f53000     0x7ffff7fa9000    0x56000   0x192000  r--p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7fa9000     0x7ffff7faa000     0x1000        0x0  ---p
>>>         0x7ffff7faa000     0x7ffff7fae000     0x4000   0x1e8000  r--p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>>         0x7ffff7fae000     0x7ffff7fb0000     0x2000   0x1ec000  rw-p   /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> Mm, was staring on this for a while,
>> and file offsets and perms looks the
>> same. What differences do you mean
>> exactly?
> The PROT_NONE mapping now does not have a file associated:
>
>    0x7ffff7fa9000     0x7ffff7faa000     0x1000        0x0  ---p
>
> This is not a problem itself, but again this change decrease the information
> that some tools might use to analyze the memory mapping.

Ah, that seems to be a "hole" are
between segments. I actually think
my handling is much better. Without
my patch, such holes are filled with
actually the _random_ page from the
original file mapping. Just whatever
page happened to have that offset.
Do you think the random page from
the file is a good idea for tooling/debugging?