[Bug dynamic-link/31076] Extra struct vm_area_struct with ---p created when PAGE_SIZE < max-page-size

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31076

--- Comment #20 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Fangrui Song from comment #19)
> (In reply to Florian Weimer from comment #18)
> > (In reply to Kalesh Singh from comment #15)
> > > AIUI if the runtime-page-size equals the max-page-size, the holes are also
> > > mapped in as part of the segment mapping and share the same permissions.
> > > Does this mean that on such systems, any protection it offers becomes void?
> > 
> > That's my understanding. The current behavior gives programmers the *option*
> > to avoid mapping extra code on small-page systems, while maintaining
> > compatibility with large-page systems. The proposed change to over-map to
> > the next load-segment, to fill the gap, would take away that option.
> 
> Can you elaborate what the option (and "functionality" below) is? Since
> 22930c9bf21ea15d0da1477a379029e2de259b69 (1996) rtld just calls `mprotect`
> (one
> extra `struct vm_area_struct` instance, see `sudo grep vm_area_struct
> /proc/slabinfo`), and the user has no option to control this behavior.

The developer can produce a binary with a LOAD segment that does not need that
mprotect call.

> > Unmapping (to create a gap) has compatibility implications.
> 
> I wonder the implications are. If they are related to l_contiguous not
> accounted for correctly, the user needs to be fixed.

We do not set l_contiguous for the dynamic loader, and it's an internal
variable. The bug we have is that we assume (without checking) the the loader
is mapped contiguously although the kernel does not do that.

We have feedback from downstream that some tools break if the gaps are so large
that objects are mapped in the gaps of other objects. This is particularly
visible on x86-64 when objects linked with different binutils versions/flags
are loaded because the gaps can be quite large due to 2 MiB load segment
alignment in some builds. Other objects do not do that alignment and are much
smaller than 2 MiB, and so can fit comfortably into the gaps. I'm worried that
if we change loader behavior to munmap instead of mprotect, that we'll
retroactively expose these bugs more widely.

We obviously need to fix the l_contiguous assumption for ld.so in glibc, either
by making sure that ld.so has contiguous load segments, or assuming in the code
that it does not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.