all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: 16343@debbugs.gnu.org
Cc: emacs@gentoo.org
Subject: bug#16343: 24.3; Failure in unexec with hardened Linux kernel
Date: Sat, 4 Jan 2014 22:56:07 +0100	[thread overview]
Message-ID: <21192.33655.545211.967095@a1i15.kph.uni-mainz.de> (raw)

Forwarding downstream bug <https://bugs.gentoo.org/456970>.

Emacs 24.3 fails to build on Linux 3.11.7 with grsecurity/PaX patches,
e.g., grsecurity-2.9.1-3.11.7-201311102306.patch from
<http://grsecurity.net/>. This configuration is used in Gentoo with
sys-kernel/hardened-sources-3.11.7-r1.

The build process fails in unexec, the same way it previously did in
bug #11398:

   Dumping under the name emacs
   **************************************************
   Warning: Your system has a gap between BSS and the
   heap (15854248 bytes).  This usually means that exec-shield
   or something similar is in effect.  The dump may
   fail because of this.  See the section about
   exec-shield in etc/PROBLEMS for more information.
   **************************************************
   /bin/sh: Zeile 6: 29064 Speicherzugriffsfehler  `/bin/pwd`/temacs --batch --load loadup bootstrap
   make[1]: *** [bootstrap-emacs] Fehler 1

The reason that it fails again is that the PaX kernel switched from
setting PaX flags in the program header to extended file attributes
(that is, XATTR_PAX_FLAGS=y instead of PT_PAX_FLAGS=y in the kernel's
configuration). Therefore running paxctl on temacs is no longer
sufficient, but setfattr needs to be called.

The patch included below was tested with Emacs 24.3 and fixes the
problem. I've rebased it on the bzr trunk as of today, though.

Please note that extended attributes for temacs are set when they are
supported and when the setfattr program is available, regardless if
the kernel is hardened or not. They will not harm, but simply be
ignored in the latter case. Also the temacs binary is not being
installed, so the installed files will not change. (Contrary to the
paxctl method, the emacs binary doesn't "inherit" extended attributes
from temacs, so there is no need to unset them.)


--- old/configure.ac	2014-01-01 08:31:29 +0000
+++ new/configure.ac	2014-01-04 20:49:13 +0000
@@ -990,6 +990,18 @@
   fi
 fi
 
+AC_PATH_PROG(SETFATTR, setfattr)
+if test "X$SETFATTR" != X; then
+  AC_MSG_CHECKING([whether extended attributes are supported])
+  touch conftest.tmp
+  if $SETFATTR -n user.pax.flags conftest.tmp >/dev/null 2>&1; then
+    AC_MSG_RESULT(yes)
+  else
+    AC_MSG_RESULT(no); SETFATTR=""
+  fi
+  rm -f conftest.tmp
+fi
+
 ## Need makeinfo >= 4.7 (?) to build the manuals.
 AC_PATH_PROG(MAKEINFO, makeinfo, no)
 dnl By this stage, configure has already checked for egrep and set EGREP,
--- old/src/Makefile.in	2014-01-01 07:43:34 +0000
+++ new/src/Makefile.in	2014-01-04 20:49:13 +0000
@@ -114,6 +114,9 @@
 ## memory randomization in temacs with "paxctl -r".  See bug#11398.
 PAXCTL = @PAXCTL@
 
+## If available, the full path to the setfattr program.
+SETFATTR = @SETFATTR@
+
 ## Some systems define this to request special libraries.
 LIBS_SYSTEM=@LIBS_SYSTEM@
 
@@ -494,6 +497,8 @@
 	$(TEMACS_POST_LINK)
 	test "$(CANNOT_DUMP)" = "yes" || \
 	  test "X$(PAXCTL)" = X || $(PAXCTL) -r temacs$(EXEEXT)
+	test "$(CANNOT_DUMP)" = "yes" || test "X$(SETFATTR)" = X || \
+	  $(SETFATTR) -n user.pax.flags -v r temacs$(EXEEXT)
 
 ## The following oldxmenu-related rules are only (possibly) used if
 ## HAVE_X11 && !USE_GTK, but there is no harm in always defining them.





             reply	other threads:[~2014-01-04 21:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-04 21:56 Ulrich Mueller [this message]
2014-01-05  1:03 ` bug#16343: 24.3; Failure in unexec with hardened Linux kernel Paul Eggert
2014-01-05  3:20   ` Ulrich Mueller
2014-01-05  4:57     ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21192.33655.545211.967095@a1i15.kph.uni-mainz.de \
    --to=ulm@gentoo.org \
    --cc=16343@debbugs.gnu.org \
    --cc=emacs@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.