[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23529: Request for fixing randomize_va_space build issues

From: Paul Eggert
Subject: bug#23529: Request for fixing randomize_va_space build issues
Date: Wed, 18 May 2016 01:21:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

Some background: Emacs has an 'undump' function that saves the Emacs state as an
executable: when you run the executable, you get an Emacs with the same (or
nearly the same) state. This makes Emacs startup considerably faster. Objects in
the restored state must be in the same location as when they were saved, so the
executable cannot be subject to ASLR.

On 05/17/2016 09:38 AM, Philippe Vaucher wrote:

> Some information about why the personality syscall is disabled in my env:
> https://github.com/docker/docker/blob/master/docs/security/seccomp.md

That says the 'personality' syscall is "Not inherently dangerous, but poorly
tested". Although this justifies paranoia in some applications, we are talking
*Emacs* here. (People worried about poorly tested code should not be running
Emacs. :-) So a simple way to fix the problem, as I guess you've discovered, is
to allow the 'personality' syscall in your Docker image.

I don't know all the ins and outs of why it is necessary for Emacs to invoke
'personality'. As I understand it, the build procedure should invoke the shell
command 'setfattr -n user.pax.flags -v er temacs' immediately after building
temacs, and I don't know why this doesn't make the 'personality' call
unnecessary. Perhaps you can consult a seccomp expert who can tell you what's
going on, as seccomp is not well-documented. If there is some way to disable
ASLR without calling 'personality', that should fix your problem.

Regardless, the advice in etc/PROBLEMS is clearly obsolete here, so I installed
the attached patch to try to make things clearer. We're not going to greatly
alter the dumping procedure before Emacs 25 comes out (it's too late in the
release process) but we should do better in the future. For now we should at
least document the issues better.

> I tried to run "./temacs --batch --load loadup bootstrap" inside GDB
> to get more insights about why it segfaults there, but somehow gdb
> fails to catch it. Maybe because of spawned processes?

Yes, the code you highlighted does an execvp. You might try fiddling with GDB's
follow-exec-mode variable; see

Attachment: 0001-Modernize-ASLR-advice-in-etc-PROBLEMS.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]