Re: glibc: loading of shared objects with holes wastes address space

[Mathias Krause <minipli at googlemail dot com>]

On Fri, Oct 14, 2011 at 6:42 PM, Roland McGrath <roland@hack.frob.com> wrote:
> Mapping past the end of a file is not a problem.
> It has perfectly well-defined semantics.

It does, but creating a mapping that covers the whole file and even
more beyond EOF with the flags of the first segment is not nice. It
makes parts of the shared object executable that should not be. For
only a short amount of time, though. Nevertheless, nothing one would
expect from happening.

> The behavior of occupying holes with PROT_NONE regions is what's
> intended. ?It was done this way because the previous behavior led to
> undesireable results. ?When holes of a page or more were left, then
> unrelated later mappings would go there. ?This created situations where
> memory-access bugs could have extremely strange results. ?For example,
> the gap would often be filled by an allocation done for malloc. ?Then a
> buggy program that wrote off the end of the allocation would clobber
> some library's data segment, which is much harder to figure out in
> debugging than if it just clobbered some other malloc region.

I see. So the real problem are the holes themselves. If there wouldn't
be any gap between two adjacent segments, then there would be no need
to stuff them. And honestly, currently those holes are not needed at
all. Neither the glibc nor the kernel seem to honor the alignment
requirements when searching for a suitable address. So the question
is: Why are the sections in the linker script aligned to MAXPAGESIZE
instead of PAGESIZE, i.e. aligned to 2 MiB instead of 4 KiB? But it
looks like this is more of a question for the binutils folks (CCed).

> So we're not going to back to how it was.
>
> A change that I think would be reasonable is to extend the PROT_NONE
> blackout regions only as far as the segment size rounded to p_align.
> With normal objects, there won't be any gap beyond that. ?With your
> objects that use an unusual layout, the PROT_NONE region will still
> cover the space that the phdrs say the object expects to be covered, but
> not the whole region up until the next segment. ?A cleanly-written patch
> to implement that behavior would be fine with me.

That wouldn't prevent anonymous mappings to get placed right below a
writable mapping of the shared object. Then, again, your sketched bug
scenario with out-of-bounds access could happen.

Regards,
Mathias