GNU bug report logs - #11398
24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11398 in the body.
You can then email your comments to 11398 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: bug-gnu-emacs <at> gnu.org
Cc: Jan Djärv <jan.h.d <at> swipnet.se>
Subject: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Thu, 3 May 2012 11:12:00 +0200

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

Emacs 23.4 and 24.0.95 both fail to build on a Gentoo system with a
sys-kernel/hardened-sources-3.3* kernel, i.e. Linux 3.3* with the
grsecurity/PaX patches from <http://grsecurity.net/>
(e.g., grsecurity-2.9-3.3.4-201204272006.patch).

   Dumping under the name emacs
   **************************************************
   Warning: Your system has a gap between BSS and the
   heap (15045480 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.
   **************************************************
   make[1]: *** [bootstrap-emacs] Segmentation fault
   make[1]: Leaving directory `/var/tmp/portage/app-editors/emacs-23.4-r1/work/emacs-23.4/src'
   make: *** [src] Error 2

Since it still could be successfully built with hardened-sources-3.2*,
we had first reported this problem to grsecurity/PaX upstream.
However, they claim that it is due to a bug in Emacs' unexec code.

Quoting from <https://bugs.gentoo.org/show_bug.cgi?id=411439#c13> and
following comments:

| i've debugged the problem and it's a bug in emacs. it wants to create
| a memory dump of its address space without actually looking at what
| memory ranges are available with what access rights. due to recentish
| changes in PaX the gap between the end of the main executable's data
| section and the start of the brk heap is mapped with PROT_NONE rights,
| so no access is allowed and this is where emacs fails.

| ADDR_NO_RANDOMIZE was added as a workaround to fix userland bugs
| like what emacs has (the first bug is about assuming a particular
| address space layout that no standard has ever guaranteed, the
| second bug is that emacs doesn't use the kernel provided interface
| to discover its own address space layout).

| [...] fundamentally a bug in emacs's memory dumper code, the proper
| fix should be in there.

Could GNU Emacs upstream comment on this, please?

Ulrich

Message #10 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: 11398 <at> debbugs.gnu.org
Subject: Re: bug#11398: Acknowledgement (24.0.95; Segfault in unexec on Linux
	3.3* with grsecurity/PaX)
Date: Thu, 17 May 2012 23:13:08 +0200

>>>>> On Thu, 10 May 2012, Glenn Morris wrote:

> forwarded 11398 https://bugs.gentoo.org/show_bug.cgi?id=411439

Could you please explain? Does this mean that you don't consider this
as an Emacs problem, but that the bug should be resolved at the distro
level?

Message #13 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 11398 <at> debbugs.gnu.org
Subject: Re: bug#11398: Acknowledgement (24.0.95;
	Segfault in unexec on Linux 3.3* with grsecurity/PaX)
Date: Thu, 17 May 2012 17:16:16 -0400

Ulrich Mueller wrote:

>> forwarded 11398 https://bugs.gentoo.org/show_bug.cgi?id=411439
>
> Could you please explain?

I use forwarded as simply a way to add a hyperlink to a place with more
information in the web version of the debbugs report.

>  Does this mean that you don't consider this as an Emacs problem, but
> that the bug should be resolved at the distro level?

No (I would have said something).

Message #16 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: 11398 <at> debbugs.gnu.org
Subject: Re: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Sun, 27 May 2012 14:18:30 +0200

The patch included below (against trunk of today) fixes the problem
for me.

I've not added a configure option to control usage of paxctl, because:
- Generally, the paxctl utility should be available on PaX enabled
  Linux systems.
- On non-PaX systems (but where paxctl exists for some reason) it is
  harmless if the PaX flags of temacs are modified. In any case, the
  flags of the final emacs binary will be restored to their default.


--- emacs-orig/ChangeLog
+++ emacs/ChangeLog
@@ -1,3 +1,7 @@
+2012-05-27  Ulrich Müller  <ulm <at> gentoo.org>
+
+	* configure.in (PAXCTL): Check for paxctl. (Bug#11398)
+
 2012-05-27  Paul Eggert  <eggert <at> cs.ucla.edu>
 
 	Assume gnulib does largefile.
--- emacs-orig/configure.in
+++ emacs/configure.in
@@ -713,6 +713,8 @@
 AC_PATH_PROG(INSTALL_INFO, install-info,:, /sbin)
 dnl Don't use GZIP, which is used by gzip for additional parameters.
 AC_PATH_PROG(GZIP_PROG, gzip)
+AC_PATH_PROG(PAXCTL, paxctl,,
+  [$PATH$PATH_SEPARATOR/sbin$PATH_SEPARATOR/usr/sbin])
 
 
 ## Need makeinfo >= 4.7 (?) to build the manuals.
--- emacs-orig/src/ChangeLog
+++ emacs/src/ChangeLog
@@ -1,3 +1,11 @@
+2012-05-27  Ulrich Müller  <ulm <at> gentoo.org>
+
+	* Makefile.in (PAXCTL): Define.
+	(temacs$(EXEEXT)): Disable memory randomization for the temacs
+	binary via PaX flags if the paxctl utility is available.
+	(emacs$(EXEEXT), bootstrap-emacs$(EXEEXT)): Restore PaX flags to
+	their default. (Bug#11398)
+
 2012-05-27  Paul Eggert  <eggert <at> cs.ucla.edu>
 
 	* lisp.h [REL_ALLOC]: Omit duplicate prototypes.
--- emacs-orig/src/Makefile.in
+++ emacs/src/Makefile.in
@@ -113,6 +113,12 @@
 ## $LDFLAGS or empty if NS_IMPL_GNUSTEP (for some reason).
 TEMACS_LDFLAGS2 = @TEMACS_LDFLAGS2@
 
+## If available, the full path to the paxctl program.
+## 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.
+PAXCTL = @PAXCTL@
+
 ## Some systems define this to request special libraries.
 LIBS_SYSTEM=@LIBS_SYSTEM@
 
@@ -403,6 +409,7 @@
 	    -f list-load-path-shadows || true; \
 	else \
 	  LC_ALL=C $(RUN_TEMACS) -batch -l loadup dump || exit 1; \
+	  test "X$(PAXCTL)" = X || $(PAXCTL) -zex emacs$(EXEEXT); \
 	  ln -f emacs$(EXEEXT) bootstrap-emacs$(EXEEXT); \
 	  ./emacs -batch -f list-load-path-shadows || true; \
 	fi
@@ -450,6 +457,8 @@
 temacs$(EXEEXT): $(START_FILES) stamp-oldxmenu $(obj) $(otherobj) $(lib)/libgnu.a
 	$(CC) $(LD_FIRSTFLAG) $(ALL_CFLAGS) $(TEMACS_LDFLAGS) $(TEMACS_LDFLAGS2) \
 	  -o temacs $(START_FILES) $(obj) $(otherobj) $(lib)/libgnu.a $(LIBES)
+	test "$(CANNOT_DUMP)" = "yes" || \
+	  test "X$(PAXCTL)" = X || $(PAXCTL) -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
@@ -597,6 +606,7 @@
 	  ln -f temacs$(EXEEXT) bootstrap-emacs$(EXEEXT); \
 	else \
 	  $(RUN_TEMACS) --batch --load loadup bootstrap || exit 1; \
+	  test "X$(PAXCTL)" = X || $(PAXCTL) -zex emacs$(EXEEXT); \
 	  mv -f emacs$(EXEEXT) bootstrap-emacs$(EXEEXT); \
 	fi
 	@: Compile some files earlier to speed up further compilation.

Message #21 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 11398 <at> debbugs.gnu.org
Subject: Re: bug#11398: 24.0.95;
	Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Sun, 03 Jun 2012 19:15:55 -0400

Thanks; applied to trunk for 24.2.

I will leave this report open because IIUC this is only a workaround
(like using setarch was for Exec Shield), rather than a proper fix.

Message #26 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: "Herbert J. Skuhra" <h.skuhra <at> gmail.com>
To: 11398 <at> debbugs.gnu.org
Subject: Re: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Wed, 27 Jun 2012 11:00:02 +0200

Hi,

the changes in revno 108471 obviously break the build on NetBSD:

test "no" = "yes" || \
  test "X/usr/sbin/paxctl" = X || /usr/sbin/paxctl -r temacs
Usage: paxctl [ <-|+><A|a|G|g|M|m> ] <file> ...
gmake[2]: *** [temacs] Error 1
gmake[2]: Leaving directory `/home/herbert/source/emacs/trunk/src'
gmake[1]: *** [src] Error 2
gmake[1]: Leaving directory `/home/herbert/source/emacs/trunk'
gmake: *** [bootstrap] Error 2

% uname -rms
NetBSD 6.99.8 amd64

-- 
Herbert

Message #29 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: "Herbert J. Skuhra" <h.skuhra <at> gmail.com>
Cc: 11398 <at> debbugs.gnu.org
Subject: Re: bug#11398: 24.0.95;
	Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Wed, 27 Jun 2012 19:59:35 -0400

"Herbert J. Skuhra" wrote:

> Usage: paxctl [ <-|+><A|a|G|g|M|m> ] <file> ...

I've simply restricted the test for paxctl to GNU/Linux systems.
If someone ever reports that NetBSD actually needs to run paxctl,
a more sophisticated fix will be needed.

Message #32 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 11398 <at> debbugs.gnu.org
Subject: Re: bug#11398: 24.0.95;
 Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Wed, 28 Aug 2019 15:52:27 +0200

Ulrich Mueller <ulm <at> gentoo.org> writes:

> Forwarding downstream bug <https://bugs.gentoo.org/411439>.
>
> Emacs 23.4 and 24.0.95 both fail to build on a Gentoo system with a
> sys-kernel/hardened-sources-3.3* kernel, i.e. Linux 3.3* with the
> grsecurity/PaX patches from <http://grsecurity.net/>
> (e.g., grsecurity-2.9-3.3.4-201204272006.patch).
>
>    Dumping under the name emacs
>    **************************************************
>    Warning: Your system has a gap between BSS and the
>    heap (15045480 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.
>    **************************************************
>    make[1]: *** [bootstrap-emacs] Segmentation fault
>    make[1]: Leaving directory `/var/tmp/portage/app-editors/emacs-23.4-r1/work/emacs-23.4/src'
>    make: *** [src] Error 2
>
> Since it still could be successfully built with hardened-sources-3.2*,
> we had first reported this problem to grsecurity/PaX upstream.
> However, they claim that it is due to a bug in Emacs' unexec code.
>
> Quoting from <https://bugs.gentoo.org/show_bug.cgi?id=411439#c13> and
> following comments:
>
> | i've debugged the problem and it's a bug in emacs. it wants to create
> | a memory dump of its address space without actually looking at what
> | memory ranges are available with what access rights. due to recentish
> | changes in PaX the gap between the end of the main executable's data
> | section and the start of the brk heap is mapped with PROT_NONE rights,
> | so no access is allowed and this is where emacs fails.
>
> | ADDR_NO_RANDOMIZE was added as a workaround to fix userland bugs
> | like what emacs has (the first bug is about assuming a particular
> | address space layout that no standard has ever guaranteed, the
> | second bug is that emacs doesn't use the kernel provided interface
> | to discover its own address space layout).
>
> | [...] fundamentally a bug in emacs's memory dumper code, the proper
> | fix should be in there.
>
> Could GNU Emacs upstream comment on this, please?
>
> Ulrich

Is this still an issue with Emacs 27.0.50 (current master branch)?

etc/NEWS says:

 ** Emacs now uses a "portable dumper" instead of unexec.
 This improves compatibility with memory allocation on modern systems,
 and in particular better supports the Address Space Layout
 Randomization (ASLR) feature, a security technique used by most modern
 operating systems.

Thanks,
Stefan Kangas

Message #35 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 11398 <at> debbugs.gnu.org
Subject: Re: bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with
 grsecurity/PaX
Date: Wed, 28 Aug 2019 16:24:34 +0200

> Is this still an issue with Emacs 27.0.50 (current master branch)?

Well, grsecurity made their patches proprietary in 2017. Subsequently,
Gentoo has dropped PaX support from the Emacs package, as well as
"hardened" Linux sources. So, I no longer have access to an environment
where I could reproduce this bug.

The following posting pretty much summarises the Gentoo point of view:
https://archives.gentoo.org/gentoo-dev/message/0283ed6004111127e0e575cc912feff1

I'd suggest to close this bug. If there are similar problems with the
portable dumper, it may be cleaner to open a fresh bug for them.

Message #40 received at 11398-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 11398-done <at> debbugs.gnu.org
Subject: Re: bug#11398: 24.0.95;
 Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Wed, 28 Aug 2019 16:27:19 +0200

Ulrich Mueller <ulm <at> gentoo.org> writes:

> I'd suggest to close this bug. If there are similar problems with the
> portable dumper, it may be cleaner to open a fresh bug for them.

Thanks; closing.

Best regards,
Stefan Kangas

Message #43 received at 11398 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: ulm <at> gentoo.org, jan.h.d <at> swipnet.se, 11398 <at> debbugs.gnu.org
Subject: Re: bug#11398: 24.0.95;
 Segfault in unexec on Linux 3.3* with grsecurity/PaX
Date: Wed, 28 Aug 2019 17:51:33 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 28 Aug 2019 15:52:27 +0200
> Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 11398 <at> debbugs.gnu.org
> 
> Is this still an issue with Emacs 27.0.50 (current master branch)?
> 
> etc/NEWS says:
> 
>  ** Emacs now uses a "portable dumper" instead of unexec.
>  This improves compatibility with memory allocation on modern systems,
>  and in particular better supports the Address Space Layout
>  Randomization (ASLR) feature, a security technique used by most modern
>  operating systems.

Due to pdumper, I don't believe this could be a problem anymore.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.