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