[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11398: 24.0.95; Segfault in unexec on Linux 3.3* with grsecurity/PaX
From: |
Stefan Kangas |
Subject: |
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@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,
Stefan Kangas <=