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

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
In ancient times, ldso used to unmap the disjoined regions from PT_LOAD.  It
was changed decades ago (22930c9bf21ea15d0da1477a379029e2de259b69), most likely
due some kernel VMA limitation since it done between Linux 1.3 to 2.0 release. 
Changing back to unmap should remove the extra VMA ranges:

diff --git a/elf/dl-load.h b/elf/dl-load.h
index 1d5207694b..f53983fd1f 100644
--- a/elf/dl-load.h
+++ b/elf/dl-load.h
@@ -124,6 +124,8 @@ static const char *_dl_map_segments (struct link_map *l,
int fd,
    guaranteed to have translations.  */
 #define DL_MAP_SEGMENTS_ERROR_MAP_SEGMENT \
   N_("failed to map segment from shared object")
+#define DL_MAP_SEGMENTS_ERROR_UNMAP_SEGMENT \
+  N_("failed to unmap segment from shared object")
 #define DL_MAP_SEGMENTS_ERROR_MPROTECT \
   N_("cannot change memory protections")
 #define DL_MAP_SEGMENTS_ERROR_MAP_ZERO_FILL \
diff --git a/elf/dl-map-segments.h b/elf/dl-map-segments.h
index ac10182d58..7ecb1d917b 100644
--- a/elf/dl-map-segments.h
+++ b/elf/dl-map-segments.h
@@ -115,11 +115,10 @@ _dl_map_segments (struct link_map *l, int fd,
          if (__glibc_unlikely (loadcmds[nloadcmds - 1].mapstart <
                                c->mapend))
            return N_("ELF load command address/offset not page-aligned");
-          if (__glibc_unlikely
-              (__mprotect ((caddr_t) (l->l_addr + c->mapend),
-                           loadcmds[nloadcmds - 1].mapstart - c->mapend,
-                           PROT_NONE) < 0))
-            return DL_MAP_SEGMENTS_ERROR_MPROTECT;
+         if (__glibc_unlikely
+             (__munmap ((caddr_t) (l->l_addr + c->mapend),
+                        loadcmds[nloadcmds - 1].mapstart - c->mapend) < 0))
+            return DL_MAP_SEGMENTS_ERROR_UNMAP_SEGMENT;
         }

       l->l_contiguous = 1;

It would be somewhat more coslty, since kernel will need to remap and split the
VMA range.

However, it is not really clear to me what is the advantage of mprotect/munmap
the scenario where the PT_LOAD might have 'holes' (essentially where the system
page size is lower than the required alignment).  I can understand the munmap,
since it might have some sense back on 32 bit deployments were common and VMA
range was scarse in some situation (specially due fragmentation).

But the mprotect does not relly bring any advantage here, it consumes more
kernel metadata, do not improve the process VMA range usage, nor it was done as
a hardening scheme.

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