Re: Dumper problems and a possible solutions

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 25 Jun 2014 15:03:33 -0400
> From: Rich Felker <dalias@libc.org>
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> 
> > > > Is it possible to provide our own implementation of sbrk that
> > > > allocates memory from some large static array?
> > > 
> > > That's exactly the hack I described which I'm using right now. But
> > > since I didn't implement a free-like operation and since
> > > load_charset_map_from_file allocates >700k every time it's called, I
> > > had to make the static array 400MB.
> > 
> > That's not a problem, because those 700K are free'd before the next
> > one is allocated.  And in any case, they are all free'd before we call
> > unexec.  Just implement sbrk for negative increment.  The Windows port
> 
> But load_charset_map_from_file doesn't call an sbrk-like interface; it
> calls (indirectly) xmalloc and xfree. So there's at least some
> nontrivial glue that goes in between.

Sorry, you are right.  What you need is non-toy malloc implementation
that is willing to work with your replacement sbrk.  Then support for
negative increments in sbrk isn't required.

But I still don't understand how you get to 400MB.  It's not that we
allocate hundreds of those 700K tables for charsets.  Do you have an
explanation for this?

> > If supporting deallocation in such an sbrk isn't feasible, how about
> > using gmalloc, as an malloc replacement before dumping?
> 
> I suspect it's a lot of work to wire up gmalloc to (1) avoid
> interposing on the malloc/free/etc. names, (2) use the static mini-brk
> buffer, (3) only allocate from the mini-brk buffer before dumping
> (otherwise pass to real malloc), but still check realloc/free calls
> after dumping and handle the case where the old memory was in the
> mini-brk.

Sorry, I don't see the difficulty.  Just make malloc/realloc/free be
pointers that point to gmalloc's implementation before dumping, and to
the libc implementation after it.  You may need some #define to rename
malloc to some other symbol, to avoid name clashes.  Am I missing
something?

> What seems easier, and what I tried, is writing a completely naive
> malloc with a single freelist that's linear-searched on malloc and
> which does not support coalescing free chunks. But I think my
> implementation has some bugs still, because it's not working.

The advantage of gmalloc is that it works out of the box.

> > > I would be reasonably happy with this solution (at least it would fix
> > > the problems I'm experiencing), but I don't think it's as elegant as
> > > fixing the portability problem completely by getting rid of the need
> > > to dump executable binary files and instead dumping a C array.
> > 
> > But it's conceptually much simpler and reliable.  That's "elegant" in
> > my book, when such hairy stuff is concerned.
> 
> No, it's less reliable. See my other posts in the thread about what
> happens if you have other libraries linked and they do nontrivial
> things prior to dumping (e.g. from static ctors).

But in those other posts I thought we agreed that whatever those ctors
do is irrelevant, as the dumped Emacs cannot possibly use what they
allocate, and those ctors will be invoked again in the dumped Emacs.

> As an example (I think I mentioned this earlier), if you static
> link, musl libc is remembering the clock_gettime vdso pointer from
> the pre-dump state and attempting to use it later (which is not
> valid because the kernel maps it at a random address).

You need to fix your libc to detect that it is re-exec'ed, and
re-initialize this stuff.

> > > And it doesn't fix the fact that you can't build a PIE emacs.
> > 
> > Why is that important?
> 
> Since emacs is processing lots of potentially untrusted data, PIE
> hardening may be beneficial for hardening against vulnerabilities
> where an attacker would otherwise be able to perform arbitrary code
> execution as the user running emacs. I'm not aware of such
> vulnerabilities, but being that I found things that look suspiciously
> like use-after-free while reading the allocator-related code, I
> wouldn't be surprised if they exist.

Sounds like a secondary requirement to me.  We should first make the
dumping work along these lines, and worry about bonuses later.