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