bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Ulrich Mueller]

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

bug#11398: Acknowledgement (24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX)

[Ulrich Mueller]

>>>>> 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?

bug#11398: Acknowledgement (24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX)

[Glenn Morris]

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

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Ulrich Mueller]

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@gentoo.org>
+
+	* configure.in (PAXCTL): Check for paxctl. (Bug#11398)
+
 2012-05-27  Paul Eggert  <eggert@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@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@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.

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Glenn Morris]

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.

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Herbert J. Skuhra]

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

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Glenn Morris]

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

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Stefan Kangas]

Ulrich Mueller <ulm@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

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Ulrich Mueller]

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

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Stefan Kangas]

Ulrich Mueller <ulm@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

bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 28 Aug 2019 15:52:27 +0200
> Cc: Jan Djärv <jan.h.d@swipnet.se>, 11398@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.