[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 #9 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Florian Weimer from comment #8)
> (In reply to Adhemerval Zanella from comment #7)
> > 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,
> 
> There's no expectation that these are contiguous in memory, yes. Such an
> expectation exists for shared objects loaded by glibc.

Right, but my point is if this is a hardening feature that glibc aims to
provide it does not help if the kernel still does not provide it for the loader
(if this is built with a different page size) and the main program itself.
Should we push for kernel to implement a similar handling?

And the holes seem to be always from the initial read-only segment, which makes
the whole gadget avoidance argument moot. This would make sense back when RELRO
was not wildly used/deployed (even with the current somewhat broken status),
but it still does not make much sense to me.

> 
> > and IMHO it should
> > up to the static linker to fill the padding with NOP/trap instruction to
> > avoid such issues. 
> 
> That requires padding to the maximum page size on disk, though.

But this is what binutils does [1], and while not being optimized it seems that
it would be somewhat hard to fix it (at least with Fangrui Song suggestion).

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30612

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