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

[Adhemerval Zanella Netto]

On 29/03/23 15:46, stsp wrote:
> 
> 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.

It avoid code duplication.

> 
>>>> 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.

In fact I think this is gdb limitation, accessing the procfs directly there is
no extra mapping and all the segments are indeed mapped by associated shared
libraries.

> 
>>>> 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?

It seems to be a gdb limitation that is showing some wrong information.  But again,
I really don't see *why* this change is needed: the current algorithms already
maps the ELF segments correctly and have random data on the hole does not really
matter (it would be mapped as PROT_NONE).