Executable memory: further programs that fail

[Roland McGrath]

> Yes, you've explained that there is a long-way-around method
> to tell the linker that I want free space reserved. Yes,
> that is sufficient for my needs. It is also painful to implement.

Indeed it is somewhat of a nuisance to produce a PT_LOAD segment with no
protection bits set so that you get the effect of a PROT_NONE mapping that
you can overwrite later.  However, it is trivial to just have a huge bss
that you can remap later.  The only difference is that before you do any
mmap or mprotect calls to set up that area how you want it, you will have
zero-fill pages if you touch there instead of faulting if you touch there,
and that it will always be at the end of your data segment instead of being
able to use disjoint parts of the address space.  Since what you do now is
to rely on large brk allocations, I imagine you won't mind those issues
since preallocating huge amounts of bss is exactly equivalent to that. 

Also, as both Ingo and I have already said, you can reasonably expect quite
large contiguous mmaps to work (in fact, larger than with traditional Linux
layout when using shared libraries and a normal ELF executable).  That is
quite a different thing from presuming ahead of time exactly what addresses
they might return.

> Clearly such a pervasive and intrusive change to the expected unix memory
> model has a strong justification based on improving security.

The difficulty I'm having in trying to have a constructive discussion with
you is the assumption embodied in this statement.  If you are talking about
the detached brk area, I've already said that I consider that a change in
the specified Unix memory model--yet it's hardly "pervasive", it's exactly
one thing.  But I think you are in fact talking about the randomization of
mmap address allocations.  In that regard, there is absolutely zero change
to the "expected Unix memory model"--as long as there has been mmap, the
specification has been that you cannot rely on the addresses it will give
you in any particular regard, and that the expectation of being able to
mmap very large contiguous regions is an entirely reasonable demand on the
quality of implementation but by no means accomplished through application
presumption of address space layout.  I have said all of this before, but
you seem to have ignored it without even an attempt at refutation.

> If I've found a way to take control of your machine by some exploit how
> does randomly placing shared libraries keep your computer secure? 

That question is not germane--its antecedent removes it from the set of
cases any of us has raised in discussion.  In the context where some
exploit has already succeeded in taking over a process, then obviously it
is irrelevant what measures that process might earlier have taken to avoid
an exploit succeeding in taking over.  (Similarly, "A implies A" is a true
statement.)  Ingo has documented the kinds of exploits that the
randomization of mapping addresses prevents.  Noone suggests that it does
much of anything for security other than to prevent these particular modes
of exploit.  If you have not found Ingo's write-ups or they have not
adequately explained the exploit attempts thwarted by the exec-shield
changes, then we will endeavor to better document the rationale.