* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX @ 2012-05-03 9:12 Ulrich Mueller [not found] ` <handler.11398.B.133603645729820.ack@debbugs.gnu.org> ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Ulrich Mueller @ 2012-05-03 9:12 UTC (permalink / raw) To: 11398 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <handler.11398.B.133603645729820.ack@debbugs.gnu.org>]
* bug#11398: Acknowledgement (24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX) [not found] ` <handler.11398.B.133603645729820.ack@debbugs.gnu.org> @ 2012-05-17 21:13 ` Ulrich Mueller 2012-05-17 21:16 ` Glenn Morris 2012-05-27 12:18 ` bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX Ulrich Mueller 1 sibling, 1 reply; 11+ messages in thread From: Ulrich Mueller @ 2012-05-17 21:13 UTC (permalink / raw) To: 11398 >>>>> 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: Acknowledgement (24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX) 2012-05-17 21:13 ` bug#11398: Acknowledgement (24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX) Ulrich Mueller @ 2012-05-17 21:16 ` Glenn Morris 0 siblings, 0 replies; 11+ messages in thread From: Glenn Morris @ 2012-05-17 21:16 UTC (permalink / raw) To: Ulrich Mueller; +Cc: 11398 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). ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX [not found] ` <handler.11398.B.133603645729820.ack@debbugs.gnu.org> 2012-05-17 21:13 ` bug#11398: Acknowledgement (24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX) Ulrich Mueller @ 2012-05-27 12:18 ` Ulrich Mueller 2012-06-03 23:15 ` Glenn Morris 1 sibling, 1 reply; 11+ messages in thread From: Ulrich Mueller @ 2012-05-27 12:18 UTC (permalink / raw) To: 11398 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX 2012-05-27 12:18 ` bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX Ulrich Mueller @ 2012-06-03 23:15 ` Glenn Morris 0 siblings, 0 replies; 11+ messages in thread From: Glenn Morris @ 2012-06-03 23:15 UTC (permalink / raw) To: Ulrich Mueller; +Cc: 11398 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX 2012-05-03 9:12 bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX Ulrich Mueller [not found] ` <handler.11398.B.133603645729820.ack@debbugs.gnu.org> @ 2012-06-27 9:00 ` Herbert J. Skuhra 2012-06-27 23:59 ` Glenn Morris 2019-08-28 13:52 ` Stefan Kangas 2 siblings, 1 reply; 11+ messages in thread From: Herbert J. Skuhra @ 2012-06-27 9:00 UTC (permalink / raw) To: 11398 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX 2012-06-27 9:00 ` Herbert J. Skuhra @ 2012-06-27 23:59 ` Glenn Morris 0 siblings, 0 replies; 11+ messages in thread From: Glenn Morris @ 2012-06-27 23:59 UTC (permalink / raw) To: Herbert J. Skuhra; +Cc: 11398 "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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX 2012-05-03 9:12 bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX Ulrich Mueller [not found] ` <handler.11398.B.133603645729820.ack@debbugs.gnu.org> 2012-06-27 9:00 ` Herbert J. Skuhra @ 2019-08-28 13:52 ` Stefan Kangas 2019-08-28 14:24 ` Ulrich Mueller 2019-08-28 14:51 ` Eli Zaretskii 2 siblings, 2 replies; 11+ messages in thread From: Stefan Kangas @ 2019-08-28 13:52 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Jan Djärv, 11398 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX 2019-08-28 13:52 ` Stefan Kangas @ 2019-08-28 14:24 ` Ulrich Mueller 2019-08-28 14:27 ` Stefan Kangas 2019-08-28 14:51 ` Eli Zaretskii 1 sibling, 1 reply; 11+ messages in thread From: Ulrich Mueller @ 2019-08-28 14:24 UTC (permalink / raw) To: Stefan Kangas; +Cc: Jan Djärv, 11398 > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX 2019-08-28 14:24 ` Ulrich Mueller @ 2019-08-28 14:27 ` Stefan Kangas 0 siblings, 0 replies; 11+ messages in thread From: Stefan Kangas @ 2019-08-28 14:27 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Jan Djärv, 11398-done 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX 2019-08-28 13:52 ` Stefan Kangas 2019-08-28 14:24 ` Ulrich Mueller @ 2019-08-28 14:51 ` Eli Zaretskii 1 sibling, 0 replies; 11+ messages in thread From: Eli Zaretskii @ 2019-08-28 14:51 UTC (permalink / raw) To: Stefan Kangas; +Cc: ulm, jan.h.d, 11398 > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-08-28 14:51 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-03 9:12 bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX Ulrich Mueller [not found] ` <handler.11398.B.133603645729820.ack@debbugs.gnu.org> 2012-05-17 21:13 ` bug#11398: Acknowledgement (24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX) Ulrich Mueller 2012-05-17 21:16 ` Glenn Morris 2012-05-27 12:18 ` bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX Ulrich Mueller 2012-06-03 23:15 ` Glenn Morris 2012-06-27 9:00 ` Herbert J. Skuhra 2012-06-27 23:59 ` Glenn Morris 2019-08-28 13:52 ` Stefan Kangas 2019-08-28 14:24 ` Ulrich Mueller 2019-08-28 14:27 ` Stefan Kangas 2019-08-28 14:51 ` Eli Zaretskii
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.