Re: [Gcl-devel] exec-shield mmap & brk randomization

[Roland McGrath]

> Bingo.  In fact, we use exactly emacs' unexec.  I'm hoping your past
> tense of the verb to break here indicates that a fix for unexec is
> already at hand?

Not exactly.  I do plan to resolve the situation in the Fedora Core 2
development cycle, but exactly how is not yet clear.  I'd like to
understand GCL's constraints as well as Emacs's before deciding what to do.

> Thankfully, GCL does not have to know precisely where its heap lower
> bound is (apart from unexec) until the first call to sbrk(0) is made,
> but we do absolutely need contiguity of this heap.  As long as you
> don't dump brk altogether, I may retain my head of hair. :-).  

Do you make many repeated sbrk calls to expand the heap?  If you make just
one big allocation and don't really care what the base address is, then
mmap is just as good for you.  However, it sounds like you want to choose
the actual address range at compile time.  Is that so?

> Only in unexec.  If emacs has a fix, we can use it directly.

But, in the binary produced by unexec, do you rely on the _end/end and
_edata/edata symbols beind adjusted to included brk data allocated by the
loadup run before the unexec?  (I haven't yet checked whether Emacs does.)
That is, if what unexec did were to just restore some particular memory
allocated in the first run, disjoint from the original data segment, would
that make you happy?

> I'm not really sure how much memory could be wasted, but this likely
> seems a very small consideration compared to the complexity of
> redesigning the garbage collector, etc.

Sure.  Contiguity is inherently limited in the ways I mentioned, but there
are plenty of reasons to like it if those limitations aren't your primary
concern.  If you like contiguity, you just need to find the best ways to
ask up front for all the contiguity you really need.

> 2) come up with a configure time absolute lower bound to the first
> sbrk after exec

That is not something you ought to try to rely on in the current situation.
It is in fact a known range at the moment, but if the brk randomization
feature remains, you can't be sure the range will remain the same, or that
a compile-time determination would apply correctly to running on slightly
different kernels or different hardware configurations.

> Else we must
> 
> 3) use setarch

This is certainly the right stop-gap solution if you are concerned about
people building GCL on FC1 tomorrow.  It's trivial to implement in the src
rpm spec, and probably not worth putting in configure now since it likely
won't be required for very long.


Thanks,
Roland