bug#23529: Request for fixing randomize_va_space build issues

[Paul Eggert <eggert@cs.ucla.edu>]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

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
<https://sourceware.org/gdb/onlinedocs/gdb/Forks.html>.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Modernize-ASLR-advice-in-etc-PROBLEMS.patch --]
[-- Type: text/x-diff; name="0001-Modernize-ASLR-advice-in-etc-PROBLEMS.patch", Size: 5183 bytes --]

From b412bcd921b4dd788c17f9077f02d1d592ea7e0a Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 18 May 2016 01:05:00 -0700
Subject: [PATCH] Modernize ASLR advice in etc/PROBLEMS

* etc/PROBLEMS (Segfault during 'make'): Modernize advice for
seccomp, Docker, and NetBSD (Bug#23529).
---
 etc/PROBLEMS | 77 +++++++++++++++++++++++++++++++++++++-----------------------
 1 file changed, 48 insertions(+), 29 deletions(-)

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index 533c4e9..8733095 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -2600,51 +2600,70 @@ See <URL:http://debbugs.gnu.org/327>, <URL:http://debbugs.gnu.org/821>.
 
 ** Dumping
 
-*** Segfault during 'make bootstrap' under the Linux kernel.
+*** Segfault during 'make'
 
-In Red Hat Linux kernels, "Exec-shield" functionality is enabled by
-default, which creates a different memory layout that can break the
-emacs dumper.  Emacs tries to handle this at build time, but if this
-fails, the following instructions may be useful.
+If Emacs segfaults when 'make' executes one of these commands:
 
-Exec-shield is enabled on your system if
+  LC_ALL=C ./temacs -batch -l loadup bootstrap
+  LC_ALL=C ./temacs -batch -l loadup dump
 
-    cat /proc/sys/kernel/exec-shield
+the problem may be due to inadequate workarounds for address space
+layout randomization (ASLR), an operating system feature that
+randomizes the virtual address space of a process.  ASLR is commonly
+enabled in Linux and NetBSD kernels, and is intended to deter exploits
+of pointer-related bugs in applications.  If ASLR is enabled, the
+command:
 
-prints a value other than 0.  (Please read your system documentation
-for more details on Exec-shield and associated commands.)
+   cat /proc/sys/kernel/randomize_va_space  # GNU/Linux
+   sysctl security.pax.aslr.global          # NetBSD
 
-Additionally, Linux kernel versions since 2.6.12 randomize the virtual
-address space of a process by default.  If this feature is enabled on
-your system, then
+outputs a nonzero value.
 
-   cat /proc/sys/kernel/randomize_va_space
+These segfaults should not occur on most modern systems, because the
+Emacs build procedure uses the command 'setfattr' or 'paxctl' to mark
+the Emacs executable as requiring non-randomized address space, and
+Emacs uses the 'personality' system call to disable address space
+randomization when dumping.  However, older kernels may not support
+'setfattr', 'paxctl', or 'personality', and newer Linux kernels have a
+secure computing mode (seccomp) that can be configured to disable the
+'personality' call.
 
-prints a value other than 0.
+It may be possible to work around the 'personality' problem in a newer
+Linux kernel by configuring seccomp to allow the 'personality' call.
+For example, if you are building Emacs under Docker, you can run the
+Docker container with a security profile that allows 'personality' by
+using Docker's --security-opt option with an appropriate profile; see
+<https://docs.docker.com/engine/security/seccomp/>.
 
-When these features are enabled, building Emacs may segfault during
-the execution of this command:
+To work around the ASLR problem in either an older or a newer kernel,
+you can temporarily disable the feature while building Emacs.  On
+GNU/Linux you can do so using the following command (as root).
 
-    ./temacs --batch --load loadup [dump|bootstrap]
+    echo 0 > /proc/sys/kernel/randomize_va_space
 
-To work around this problem, you can temporarily disable these
-features while building Emacs.  You can do so using the following
-commands (as root).  Remember to re-enable them when you are done,
-by echoing the original values back to the files.
+You can re-enable the feature when you are done, by echoing the
+original value back to the file.  NetBSD uses a different command,
+e.g., 'sysctl -w security.pax.aslr.global=0'.
 
-    echo 0 > /proc/sys/kernel/exec-shield
-    echo 0 > /proc/sys/kernel/randomize_va_space
+Alternatively, you can try using the 'setarch' command when building
+temacs like this, where -R disables address space randomization:
 
-Or, on x86, you can try using the 'setarch' command when running
-temacs, like this:
+    setarch $(uname -m) -R make
 
-    setarch i386 -R ./temacs --batch --load loadup [dump|bootstrap]
+ASLR is not the only problem that can break Emacs dumping.  Another
+issue is that in Red Hat Linux kernels, Exec-shield is enabled by
+default, and this creates a different memory layout.  Emacs should
+handle this at build time, but if this fails the following
+instructions may be useful.  Exec-shield is enabled on your system if
 
-or
+    cat /proc/sys/kernel/exec-shield
+
+prints a nonzero value.  You can temporarily disable it as follows:
 
-    setarch i386 -R make
+    echo 0 > /proc/sys/kernel/exec-shield
 
-(The -R option disables address space randomization.)
+As with randomize_va_space, you can re-enable Exec-shield when you are
+done, by echoing the original value back to the file.
 
 *** temacs prints "Pure Lisp storage exhausted".
 
-- 
2.5.5