On Wed, Apr 27, 2016 at 12:38:53PM -0700, Paul Eggert wrote:
> On 04/27/2016 08:54 AM, Thomas Klausner wrote:
> >>configure.ac says
> >>that paxctl is used only when the operating system is GNU/Linux, unless one
> >>manually configures by setting PAXCTL in the environment or using a
> >>PAXCTL=/some/path argument to 'configure'.
> >That's true, but src/Makefile.in ignores that:
> >PAXCTL_if_present = $(or $(PAXCTL),: paxctl)
> 
> I guess I'm still not following. On non-GNU/Linux hosts, $(PAXCTL) should be
> empty because paxctl is not searched for, so PAXCTL_if_present should be ':
> paxctl', i.e., a no-op shell command. And yet you reported that your build
> used 'paxctl -zex' and 'paxctl -r'. Perhaps your build was actually using
> the no-ops ': paxctl -zex' and ': paxctl -r' and you didn't notice the
> colons? That is, perhaps you replaced ': paxctl -zex' (with a prefix colon)
> with 'paxctl +a' (without the colon)?

You're right, I didn't do exactly what I described.

The build system as-is does not use paxctl on NetBSD, so this breaks
when ASLR is enabled. I run the following sed expressions on
src/Makefile.in:

's,$$(PAXCTL_if_present) -zex,/usr/sbin/paxctl +a,g'
's,$$(PAXCTL_if_present) -r,/usr/sbin/paxctl +a,g'

> >My version is attached (I added some more paxctl's for the symlinks
> >when the original version didn't work.) I hope I didn't break it.
> 
> Did it work with your version?

No, I just posted it so you can see what I did.

> If so, does 'ln' and/or 'mv' remove the mark placed on an executable by
> 'paxctl +a'? and if that happens, how does 'make install' avoid removing the
> mark in the installed Emacs?
> 
> If not, then I'm afraid I'm lost.

All of cp, mv, and ln keep the paxctl settings:

# paxctl a
PaX flags:
  a: ASLR, explicit disable
# cp a b
# paxctl b
PaX flags:
  a: ASLR, explicit disable
# ln b c
# paxctl c
PaX flags:
  a: ASLR, explicit disable
# mv c d
# paxctl d
PaX flags:
  a: ASLR, explicit disable

I wasn't sure of that, so I added the extra ones, since it wasn't
working. It's not necessary, so I removed it again.

> Also, I noticed that you removed the indenting on some of the 'ifeq' lines
> in src/Makefile.in; why was that necessary?

Because the patch didn't apply cleanly, I had to manually apply it,
and I didn't indent it correctly, sorry.

So perhaps there is a different problem and paxctl is not properly
detected or applied even with your patch. Let's look more closely:

PAXCTL_dumped value:

work/emacs/config.log:PAXCTL_dumped='$(PAXCTL) +a'
work/emacs/lib/Makefile:PAXCTL_dumped = $(PAXCTL) +a
work/emacs/src/Makefile:PAXCTL_dumped = $(PAXCTL) +a

PAXCTL itself:

work/emacs/config.log:PAXCTL='/usr/sbin/paxctl'
work/emacs/lib/Makefile:PAXCTL = /usr/sbin/paxctl
work/emacs/src/Makefile:PAXCTL = /usr/sbin/paxctl

But PAXCTL_notdumped is empty.
work/emacs/config.status:S["PAXCTL_notdumped"]=""
work/emacs/lib/Makefile:PAXCTL_notdumped =
work/emacs/src/Makefile:PAXCTL_notdumped = 

On Linux this uses paxctl -r, which, according to
http://man.he.net/man1/paxctl is:

       -r     do not randomize memory regions (NORANDMMAP)

While on NetBSD, +a does:

     a     Explicitly disable PaX ASLR (Address Space Layout Randomization)
           for program.

So perhaps notdumped also needs to call paxctl +a, like my sed
expressions do.

(later)

Yes, that's it. I've defined PAXCTL_notdumped to the same value as
PAXCTL_dumped and emacs builds fine now -- basically, one additional
line to configure.ac in the netbsd case.

I'll attach my patches again, just to make it absolutely clear.

Thanks,
 Thomas