Re: kern/51654: wrong ps_strings breaks emacs20

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/51654; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/51654: wrong ps_strings breaks emacs20
Date: Sat, 26 Nov 2016 06:20:43 +0000

 On Sat, Nov 26, 2016 at 06:15:00AM +0000, David Holland wrote:
  >   >  The address space layout changed. ps_strings is placed at the very top,
  >   >  without PAX it is at a fixed address.
  >  
  >  Turning off aslr with paxctl has no effect.
 
 I take it back: making sure that emacs is dumped from a temacs with
 aslr disabled fixes the problem.
 
 But I don't follow why. Also, this doesn't explain why my preexisting
 emacs binary (which was built long before we started mucking with aslr
 this year) doesn't work and fails in the same way.
 
 Or did the default non-randomized layout also change, and by the same
 unclear mechanism thereby cause things to stop working?
 
  > >  > I haven't the slightest idea why this happens only with emacs but I
  > >  > imagine it's a consequence of the emacs dump/undump mechanism somehow.
  > >  
  > >  Combine this with the changed MAXUSER address and now certain cached
  > >  locations no longer match.
  >  
  >  Cached in what? The value for __ps_strings is provided by the kernel
  >  to crt0 and propagates to _libc_init (and causes it to croak) before
  >  anything in emacs gets control.
 
 Even if the prior value is saved when undumped, that should be
 overwritten by a new value from the current execution, no?
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost