[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

--- Comment #7 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Florian Weimer from comment #5)
> I don't see how a 152 byte struct results in 30 MB of unreclaimable kernel
> memory.  Wouldn't that need ~200,000 instances? That seems really large.
> I've only got ~70,000 lines in /proc/*/maps on this desktop system, and not
> all these mappings will exhibit this issue.
> 
> Would it help if we use MAP_FIXED with PROT_NONE to map over these unused
> parts? But as far as I understand it, these tails have not been written to,
> so it shouldn't matter if the underlying memory needs to be preserved by the
> kernel or not.
> 
> Regarding not doing the mprotect altogether, I believe this would result in
> a loss of functionality. Today, you can use the current behavior to get as
> few gadgets as possible in the process image on systems with smaller page
> sizes, while still maintaining run-time compatibility with larger page sizes
> and avoiding on-disk padding (which would increase file size). If we stop
> doing the mprotect, then the gadgets would become visible even with smaller
> page sizes. At least in principle, it should be possible for a link editor
> to produce objects that do not require tail adjustment because the load
> segments are usable as-is (but I understand that there are link editor
> limitations in this area today).

So the mprotect is essentially a hardening feature, assuming that the dynamic
object padding/holes might contain gadgets.  It still does not happen for
loader and main program itself, since normally they would be mapped by the
kernel and its does do anything with holes, and IMHO it should up to the static
linker to fill the padding with NOP/trap instruction to avoid such issues. 

So I am not fully convinced that the mprotect is really helping much here.

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