emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#16343: closed (24.3; Failure in unexec with harden


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#16343: closed (24.3; Failure in unexec with hardened Linux kernel)
Date: Sun, 05 Jan 2014 01:04:02 +0000

Your message dated Sat, 04 Jan 2014 17:03:22 -0800
with message-id <address@hidden>
and subject line 24.3; Failure in unexec with hardened Linux kernel
has caused the debbugs.gnu.org bug report #16343,
regarding 24.3; Failure in unexec with hardened Linux kernel
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
16343: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16343
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.3; Failure in unexec with hardened Linux kernel Date: Sat, 4 Jan 2014 22:56:07 +0100
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.
 address@hidden@
 
@@ -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.



--- End Message ---
--- Begin Message --- Subject: 24.3; Failure in unexec with hardened Linux kernel Date: Sat, 04 Jan 2014 17:03:22 -0800 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
Thanks very much for reporting that.  I installed a somewhat
different patch: a bit more conservative, it's used only on
GNU/Linux and doesn't attempt to find the full pathname of
setfattr, so 'configure' should run a bit faster.  Please
let me know if it doesn't work for you.  In the meantime I'm
marking the bug as done.

Here's what I installed into the trunk:

=== modified file 'ChangeLog'
--- ChangeLog   2014-01-03 01:59:58 +0000
+++ ChangeLog   2014-01-05 00:53:37 +0000
@@ -1,3 +1,10 @@
+2014-01-05  Paul Eggert  <address@hidden>
+
+       Port to GNU/Linux with recent grsecurity/PaX patches (Bug#16343).
+       Problem and proposed patch reported by Ulrich Mueller;
+       this patch uses a somewhat-different approach.
+       * configure.ac (SETFATTR): New variable.
+
 2014-01-03  Paul Eggert  <address@hidden>
Merge from gnulib, incorporating:

=== modified file 'configure.ac'
--- configure.ac        2014-01-01 08:31:29 +0000
+++ configure.ac        2014-01-05 00:59:55 +0000
@@ -988,6 +988,24 @@
       [if $PAXCTL -v conftest$EXEEXT >/dev/null 2>&1; then AC_MSG_RESULT(yes)
       else AC_MSG_RESULT(no); PAXCTL=""; fi])
   fi
+
+  if test "${SETFATTR+set}" != set; then
+    AC_CACHE_CHECK([for setfattr],
+      [emacs_cv_prog_setfattr],
+      [touch conftest.tmp
+       if (setfattr -n user.pax.flags conftest.tmp) >/dev/null 2>&1; then
+        emacs_cv_prog_setfattr=yes
+       else
+        emacs_cv_prog_setfattr=no
+       fi])
+    if test "$emacs_cv_prog_setfattr" = yes; then
+      SETFATTR=setfattr
+    else
+      SETFATTR=
+    fi
+    rm -f conftest.tmp
+    AC_SUBST([SETFATTR])
+  fi
 fi
## Need makeinfo >= 4.7 (?) to build the manuals.

=== modified file 'src/ChangeLog'
--- src/ChangeLog       2014-01-04 09:31:30 +0000
+++ src/ChangeLog       2014-01-05 00:54:04 +0000
@@ -1,3 +1,9 @@
+2014-01-05  Paul Eggert  <address@hidden>
+
+       Port to GNU/Linux with recent grsecurity/PaX patches (Bug#16343).
+       * Makefile.in (SETFATTR): New macro.
+       (temacs$(EXEEXT)): Use it.
+
 2014-01-04  Martin Rudalics  <address@hidden>
Fix maximization behavior on Windows (Bug#16300).

=== modified file 'src/Makefile.in'
--- src/Makefile.in     2014-01-01 07:43:34 +0000
+++ src/Makefile.in     2014-01-05 00:52:09 +0000
@@ -108,11 +108,12 @@
 ## Flags to pass to ld only for temacs.
 TEMACS_LDFLAGS = $(LD_SWITCH_SYSTEM) $(LD_SWITCH_SYSTEM_TEMACS)
-## If available, the full path to the paxctl program.
+## If available, the names of the paxctl and setfattr programs.
 ## On grsecurity/PaX systems, unexec will fail due to a gap between
-## the bss section and the heap.  This can be prevented by disabling
-## memory randomization in temacs with "paxctl -r".  See bug#11398.
+## the bss section and the heap.  Older versions nee paxctl to work
+## around this, newer ones setfattr.  See Bug#11398 and Bug#16343.
 PAXCTL = @PAXCTL@
+SETFATTR = @SETFATTR@
## Some systems define this to request special libraries.
 address@hidden@
@@ -494,6 +495,8 @@
        $(TEMACS_POST_LINK)
        test "$(CANNOT_DUMP)" = "yes" || \
          test "X$(PAXCTL)" = X || $(PAXCTL) -r temacs$(EXEEXT)
+       test "$(CANNOT_DUMP)" = "yes" || test -z "$(SETFATTR)" || \
+         $(SETFATTR) -n user.pax.flags -v r $@
## The following oldxmenu-related rules are only (possibly) used if
 ## HAVE_X11 && !USE_GTK, but there is no harm in always defining them.



--- End Message ---

reply via email to

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