Re: `exec shield' test in configure too strict?

[Jan D.]

>     Doesn't this harm cross-building Emacs?  I always thought that 
> running
>     a test program at configure time should be avoided, and that tests
>     that only compile or link programs should be peferred.
>
> Yes, that is true.  But maybe there is no way to test this
> based on the compilation environment.

As far as I know there isn't, the kernel controls this.  If the 
personality
of the process is PER_LINUX at startup and exec-shield is enabled, the
randomizing of the heap start address is done by the kernel.

>     When cross compiling the test obviously can not be run, so 
> configure
>     assumes
>     that the heap start address is not random.  Come to think of it, 
> the old
>     test (checking /proc/sys/kernel/exec-shield) was worse, as it did 
> not
>     handle
>     cross compiling.
>
> That will be right most of the time today, but that may not be
> true in the future.
>
> Can we modify unexec to handle this case correctly?  What exactly is
> it that we now do in the case where we see that exec shield is
> enabled?  How does that avoid the problem?

We can modify unexec I think.  Currently it memcpy:s the area from
data start to sbrk(0) (heap end) into the new data area.  But since 
there
is a hole between BSS and heap start, an invalid memory range is 
accessed
and we get a core dump:

     temacs                           Emacs
  ----------------------         ------------------
  | Data               |         |                |
  ----------------------         |                |
  | BSS                |         |                |
  ----------------------  =====> |     Data       |
  | 128-192 Mbyte hole |         |                |
  ----------------------         |                |
  | Heap               |         |                |
  ----------------------         ------------------

We could either just skip the hole and seek over it in the new data 
area,
but then the Emacs binary would be large, as the 128-192 Mbyte is added 
to
the Emacs binary size, but it has no purpose.  Another possibility is to
make a new data ELF section that contains the copied heap, and has the
correct address.  If this is feasible I don't really know, but I think
it is (I am not an ELF expert).

I previously thought that malloc needed modification, but apparently
it can handle the new hole between Emacs data and the new random heap
start address (Emacs has a zero sized BSS).

Currently we run temacs like this
% setarch i386 ./temacs ...

setarch changes personality to PER_LINUX32 and then runs temacs.  temacs
inherits the changed personality, so the kernel does not randomize the 
heap
start address.

        Jan D.