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.
next 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.