GNU bug report logs - #23529
Request for fixing randomize_va_space build issues

Previous Next

Full log

Message #83 received at 23529 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, philippe.vaucher <at> gmail.com, 23529 <at> debbugs.gnu.org
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
Date: Tue, 6 Sep 2016 13:37:20 -0700

On 09/06/2016 12:18 PM, Eli Zaretskii wrote:
> Then users on those platforms will never be able to re-dump.

True. But they'll still be better off than they are now, since they 
can't dump at all now. Plus, for extra credit we could dynamically link 
the dumped object modules at Emacs startup, with the idea of making it 
practical to re-dump.

> I actually don't understand why the data should be serialized as C
> code.  Why not just data that is read into memory (with conversion to
> the native format)?  A compiler is not the only way to convert text
> into binary data.

The compiler-based approach should be simpler and more portable than 
messing with low-level binary I/O. For example, it should be easy to 
arrange for some of the objects to be read-only: just declare them to be 
'const'. Another example: on hardened platforms with PIEs 
(position-independent executables), you get a PIE for free as the dumped 
executable, instead of having to disable PIE as we do now.

Although Emacs can do this sort of work itself (e.g., randomizing 
locations of dumped objects, munging pointers as they come in to match 
the random locations, and using mmap to make the relevant objects 
const), it should be better for Emacs to use the linking technology 
already available on modern platforms, rather than trying to reinvent 
the wheel.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.