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

Previous Next

Package: emacs;

Reported by: Philippe Vaucher <philippe.vaucher <at> gmail.com>

Date: Fri, 13 May 2016 12:20:02 UTC

Severity: important

Tags: fixed

Merged with 13964

Found in version 24.3

Fixed in version 27.1

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


Message #122 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: Fri, 9 Sep 2016 01:54:07 -0700
Eli Zaretskii wrote:

> Lisp objects are referenced through the obarray

Sure, but they are also referenced in many other ways. The obarray is just one 
corner of this.

>> Sure, but that's true of any dumping method.
>
> Writing out the dumped data is almost trivial

Not really. Not nowadays.

>> The advantage of dumping to C code is that the compiler and linker
>> will deserialize it for you.
>
> That's true, but I think you pay much more in the serialization phase.

That's fine. Serialization is rare, typically just when Emacs is built. 
Deserialization is much more common, typically whenever Emacs starts up. So it 
can be a win to speed up and simplify deserialization at the expense of 
serialization.

> the compiler and the linker were not meant for these jobs

I don't see why today's compilers and linkers wouldn't be up to these jobs. 
Emacs is not that large by today's standards. The proof of that will be in the 
pudding, no?

> writing the dumped data and then reading it with fixups is
> something we can do ourselves without relying on any external
> technologies which need to be bent to our needs.

I don't think so. We need to rely on and/or work around properties of address 
randomization which will be platform-dependent. It will be tempting to do the 
job poorly, and lose any reliability and/or security benefits of randomization 
that we might otherwise get for free. Letting the compiler and linker do this 
work for us will save us work in the long run.

> As the number of people who are able to futz with Emacs
> internals at this depth continues to dwindle,

This is exactly why we should let the compiler- and linker-writers do this work 
for us.




This bug report was last modified 5 years and 310 days ago.

Previous Next


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