emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan D.
Subject: Re: `exec shield' test in configure too strict?
Date: Thu, 7 Oct 2004 20:16:33 +0200


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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]