`exec shield' test in configure too strict?

`exec shield' test in configure too strict?

[Miles Bader]

Recently Emacs' configure script has been changed to check for the
presence of linux `exec shield' functionality, by looking for the file
/proc/sys/kernel/exec-shield, and seeing if it as a non-zero value.  If
it is present and enabled, and there's no `setarch' program available,
configure will give an error message and abort.  The reason for this, as
I understand it, is that emacs cannot dump on such a system unless it
can use the `setarch' program.

However this test seems too strict:  On fencepost.gnu.org, exec-shield
is enabled:

   $ cat /proc/sys/kernel/exec-shield
   1

and there is no setarch program:

   $ type setarch
   bash: type: setarch: not found

and so emacs refuses to configure -- but if disable this test by doing:

   $ make ac_cv_file__proc_sys_kernel_exec_shield=no

Then Emacs configures and dumps just fine, despite not using `setarch'.

Perhaps a warning (maybe in big letters) rather than a fatal error would
be appropriate.

Oh, BTW:

   $ cat /proc/version
   Linux version 2.6.7-1.494.2.2smp (bhcompile@tweety.build.redhat.com) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Tue Aug 3 09:59:49 EDT 2004

A bit odd that fencepost is running a Redhat kernel when it's a Debian
system but whatever... :-)

Thanks,

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

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

[Jan D.]

> Recently Emacs' configure script has been changed to check for the
> presence of linux `exec shield' functionality, by looking for the file
> /proc/sys/kernel/exec-shield, and seeing if it as a non-zero value.  If
> it is present and enabled, and there's no `setarch' program available,
> configure will give an error message and abort.  The reason for this, 
> as
> I understand it, is that emacs cannot dump on such a system unless it
> can use the `setarch' program.
>
> However this test seems too strict:  On fencepost.gnu.org, exec-shield
> is enabled:
>
>    $ cat /proc/sys/kernel/exec-shield
>    1
>
> and there is no setarch program:
>
>    $ type setarch
>    bash: type: setarch: not found
>
> and so emacs refuses to configure -- but if disable this test by doing:
>
>    $ make ac_cv_file__proc_sys_kernel_exec_shield=no
>
> Then Emacs configures and dumps just fine, despite not using `setarch'.

Do that machine have a /proc/sys/kernel/exec-shield-randomize file?

It is the random start address of the heap that makes dumping fail.
A test that explicitly tests for this would be best, but I'm not
sure how portable such a test would be.  Simpler then to test the
contents of /proc/sys/kernel/exec-shield-randomize if this file exists.

	Jan D.

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

[Miles Bader]

On Mon, Oct 04, 2004 at 05:04:26PM +0200, Jan D. wrote:
> >and so emacs refuses to configure -- but if disable this test by doing:
> >
> >   $ make ac_cv_file__proc_sys_kernel_exec_shield=no
> >
> >Then Emacs configures and dumps just fine, despite not using `setarch'.
> 
> Does that machine have a /proc/sys/kernel/exec-shield-randomize file?

Yes:

   $ cat /proc/sys/kernel/exec-shield-randomize
   1

> It is the random start address of the heap that makes dumping fail.

Er... don't ask me, I just know it seems to work...

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

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

[Jan D.]

> On Mon, Oct 04, 2004 at 05:04:26PM +0200, Jan D. wrote:
>>> and so emacs refuses to configure -- but if disable this test by 
>>> doing:
>>>
>>>   $ make ac_cv_file__proc_sys_kernel_exec_shield=no
>>>
>>> Then Emacs configures and dumps just fine, despite not using 
>>> `setarch'.
>>
>> Does that machine have a /proc/sys/kernel/exec-shield-randomize file?
>
> Yes:
>
>    $ cat /proc/sys/kernel/exec-shield-randomize
>    1

Incredible, I expected it to be zero.  Too bad there is a lack of
documentation on this feature.  I do know that both the compiler and
linker are involved, so maybe they have not been modified on that
machine?  Anyway, I'll try to come up with a better test where we
check the heap start address explicitly.

	Jan D.

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

[Jan D.]

>>> and so emacs refuses to configure -- but if disable this test by 
>>> doing:
>>>
>>>   $ make ac_cv_file__proc_sys_kernel_exec_shield=no
>>>
>>> Then Emacs configures and dumps just fine, despite not using 
>>> `setarch'.
>>
>> Does that machine have a /proc/sys/kernel/exec-shield-randomize file?
>
> Yes:
>
>    $ cat /proc/sys/kernel/exec-shield-randomize
>    1
>
>> It is the random start address of the heap that makes dumping fail.
>>

I have checked in a test that runs a program and sees if the heap start
address is random.  Can you try it on the Debian-with-a-Redhat-kernel
machine (I forgot its name)?

	Jan D.

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

[Stefan Monnier]

> I have checked in a test that runs a program and sees if the heap start
> address is random.  Can you try it on the Debian-with-a-Redhat-kernel
> machine (I forgot its name)?

I think there's no point bothering with that.
If /proc/sys/kernel/exec-shield is non-zero, there's a risk we may need
setarch, so if setarch is available, use it.

If /proc/sys/kernel/exec-shield is non-zero and there's no setarch, we
should just try anyway and see if it works.  If it works correctly, great.
If it doesn't work, there's little we can do anyway, so we can just output
a message referring the user to PROBLEMS.

Trying to predict whether it's going to work or not doesn't seem to make
much sense here since it doesn't allow us to resolve any problem we can't
solve otherwise.


        Stefan

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

[Jan D.]

> > I have checked in a test that runs a program and sees if the heap start
> > address is random.  Can you try it on the Debian-with-a-Redhat-kernel
> > machine (I forgot its name)?
> 
> I think there's no point bothering with that.
> If /proc/sys/kernel/exec-shield is non-zero, there's a risk we may need
> setarch, so if setarch is available, use it.
> 
> If /proc/sys/kernel/exec-shield is non-zero and there's no setarch, we
> should just try anyway and see if it works.  If it works correctly, great.
> If it doesn't work, there's little we can do anyway, so we can just output
> a message referring the user to PROBLEMS.

That would involve detetcting that the core dump from temacs is due
to exactly this problem.  I think that is hard to do.  Or do you suggest
that any temacs core dump should give a message about etc/PROBLEMS?

> Trying to predict whether it's going to work or not doesn't seem to make
> much sense here since it doesn't allow us to resolve any problem we can't
> solve otherwise.

It is so much better to get this message at configure time rather than
very late in the build stage.

	Jan D.

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

[Stefan]

>> If /proc/sys/kernel/exec-shield is non-zero and there's no setarch, we
>> should just try anyway and see if it works.  If it works correctly, great.
>> If it doesn't work, there's little we can do anyway, so we can just output
>> a message referring the user to PROBLEMS.

> That would involve detetcting that the core dump from temacs is due
> to exactly this problem.  I think that is hard to do.  Or do you suggest
> that any temacs core dump should give a message about etc/PROBLEMS?

We can output the message even if the build succeeds.
I.e. just transform the current error into a warning.

Or you could use "if the dump segfaults and /proc/../exec-shield is non-zero
and we don't have a setarch, then echo 'The problem might be due to
exec-shield, see PROBLEMS.'"

>> Trying to predict whether it's going to work or not doesn't seem to make
>> much sense here since it doesn't allow us to resolve any problem we can't
>> solve otherwise.

> It is so much better to get this message at configure time rather than
> very late in the build stage.

I don't see the big improvement here.  We're talking about a case where
Emacs's build fails.  It should be rare and we want to know about those
cases so we can fix them, so early or late detection is really not a big
deal so long as the warning is clear and visible enough.


        Stefan

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

[Miles Bader]

Stefan <monnier@iro.umontreal.ca> writes:
> I.e. just transform the current error into a warning.

I'd suggest this as the short-term fix.  It can use appropriately big
letters or whitespace or whatever, to be noticeable.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

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

[Jan D.]

Miles Bader wrote:
> Stefan <monnier@iro.umontreal.ca> writes:
> 
>>I.e. just transform the current error into a warning.
> 
> 
> I'd suggest this as the short-term fix.  It can use appropriately big
> letters or whitespace or whatever, to be noticeable.

I've used some withespace and some '***' to make it stand out.  But it still 
flashes by very fast on a reasonable new machine, so unless you are looking at 
the configure output (I usually don't) you probably will miss it.

	Jan D.

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

[Miles Bader]

"Jan D." <jan.h.d@swipnet.se> writes:
>>>I.e. just transform the current error into a warning.
>> 
>> I'd suggest this as the short-term fix.  It can use appropriately big
>> letters or whitespace or whatever, to be noticeable.
>
> I've used some withespace and some '***' to make it stand out.  But it
> still flashes by very fast on a reasonable new machine, so unless you
> are looking at the configure output (I usually don't) you probably
> will miss it.

How about outputting it again/instead at the end of the configure output
(after it prints the summary of the configuration); then it should be
just before the user's prompt.

-Miles
-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

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

[Jan D.]

> How about outputting it again/instead at the end of the configure 
> output
> (after it prints the summary of the configuration); then it should be
> just before the user's prompt.

That is a good idea, I which I had thought of that.

	Jan D.

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

[Jan D.]

Stefan wrote:

>>That would involve detetcting that the core dump from temacs is due
>>to exactly this problem.  I think that is hard to do.  Or do you suggest
>>that any temacs core dump should give a message about etc/PROBLEMS?
> 
> 
> We can output the message even if the build succeeds.

You lost me, what message?  The one in configure or the hypotetical new one 
after temacs dumps core?

> I.e. just transform the current error into a warning.

I've done that.


>>>Trying to predict whether it's going to work or not doesn't seem to make
>>>much sense here since it doesn't allow us to resolve any problem we can't
>>>solve otherwise.
> 
> 
>>It is so much better to get this message at configure time rather than
>>very late in the build stage.
> 
> 
> I don't see the big improvement here.  We're talking about a case where
> Emacs's build fails.  It should be rare and we want to know about those
> cases so we can fix them, so early or late detection is really not a big
> deal so long as the warning is clear and visible enough.

You maybe never built Emacs on a machine where the build takes 20 minutes :-)

If exec-shield and/or its effects, like randomized heap start, becomes more 
widespread this will be a very common case.  I would not be surprised if 
something like it will be incorporated in to the Linux kernel proper, and not 
just for Fedora as it is now (and some unofficial Debian patches seems to 
exist).  The undump part is not so hard to fix, but it also requires a redesign 
(more or less) of malloc, and that is harder.  Specifically malloc must be able 
to handle a heap that is not contiguous.

	Jan D.

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

[Stefan Monnier]

>> We can output the message even if the build succeeds.
> You lost me, what message?  The one in configure or the hypotetical new one
> after temacs dumps core?

I expect the message would be the same in either case (more or less), so
I just said "the" message.

>> I.e. just transform the current error into a warning.
> I've done that.

Thanks.

> You maybe never built Emacs on a machine where the build takes 20 minutes :-)

Believe me, I've done my share of building Emacs on slow machines.

> If exec-shield and/or its effects, like randomized heap start, becomes more
> widespread this will be a very common case.  I would not be surprised if
> something like it will be incorporated in to the Linux kernel proper, and
> not just for Fedora as it is now (and some unofficial Debian patches seems
> to exist).

If that's the case, then an error message (no matter how good) is *not* the
answer.  We simply do not want to go down that road: Emacs should "just
work" at least in normal (i.e. common) circumstances.


        Stefan

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

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Tue, 5 Oct 2004 22:40:02 +0200
> Cc: emacs-devel@gnu.org
> 
> I have checked in a test that runs a program and sees if the heap start
> address is random.

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.

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

[Jan D.]

>> I have checked in a test that runs a program and sees if the heap 
>> start
>> address is random.
>
> 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.

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.

	Jan D.

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

[Camm Maguire]

Greetings!

"Jan D." <jan.h.d@swipnet.se> writes:

> >> I have checked in a test that runs a program and sees if the heap
> >> start
> >> address is random.
> >
> > 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.
> 
> 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.
> 

GCL also checks for a randomized sbrk a configure time, and builds
into main a personality switch followed by a re-exec to work around
the fedora security issues.  I'm hoping this avenue won't be going
away soon, as I feel there are benefits to the current sbrk-expanding
contiguous heap design of these systems.

Don't know if there is any answer to the cross-compiling.

Take care,

> 	Jan D.
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

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

[Richard Stallman]

    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.

    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?

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.

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

[Richard Stallman]

      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).

That should be possible, if one studies the ELF specs.

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

What about running temacs this way whenever setarch exists?
If the makefile checks for the existence of setarch just before
it runs temacs, or tries first to run it using setarch and then
tries without setarch as a fallback, that would also do the job.
After all, running temacs has to be done on the actual target
platform, and then setarch ought to be available if it is needed.


Another idea: can `main' contain code to move its heap address to the
desired place, at startup?

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

[Jan D.]

Richard Stallman wrote

>     Currently we run temacs like this
>     % setarch i386 ./temacs ...
> 
> What about running temacs this way whenever setarch exists?
> If the makefile checks for the existence of setarch just before
> it runs temacs, or tries first to run it using setarch and then
> tries without setarch as a fallback, that would also do the job.
> After all, running temacs has to be done on the actual target
> platform, and then setarch ought to be available if it is needed.

Yes, it would work to first run with setarch and then normally as a fallback.

> Another idea: can `main' contain code to move its heap address to the
> desired place, at startup?

No, as the desired place is not a mapped memory region, you can not write 
there.  But we could do as described by Camm Maguire, check if the heap is not 
at the correct place at temacs startup, and if it is not, call 
personality(LINUX32) and exec() temacs again.

I think this is the best, because then temacs can output some message that 
directs the user to etc/PROBLEMS if the heap address is still off at the second 
run.

	Jan D.

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

[Richard Stallman]

    > Another idea: can `main' contain code to move its heap address to the
    > desired place, at startup?

    No, as the desired place is not a mapped memory region, you can not write 
    there.

How about mapping a memory region at the desired place, then
putting the heap address there?

I think this is the most reliable solution, since it doesn't
depend on testing the configuration in advance.  It will always
be there when it is needed.

      But we could do as described by Camm Maguire, check if the heap is not 
    at the correct place at temacs startup, and if it is not, call 
    personality(LINUX32) and exec() temacs again.

That also seems like a good method, perhaps better.  It would require
testing whether the symbols pertaining to personalites are developed,
but that is a test done by compilation, so it should be unproblematical.

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

[Jan D.]

>> Another idea: can `main' contain code to move its heap address to the
>> desired place, at startup?
>
>     No, as the desired place is not a mapped memory region, you can 
> not write
>     there.
>
> How about mapping a memory region at the desired place, then
> putting the heap address there?

It could work, but sounds tricky, you would have to mmap exactly
between BSS and the heap.  It is possible that the kernel could
reject such a request.  I haven't tested it though.

>       But we could do as described by Camm Maguire, check if the heap 
> is not
>     at the correct place at temacs startup, and if it is not, call
>     personality(LINUX32) and exec() temacs again.
>
> That also seems like a good method, perhaps better.  It would require
> testing whether the symbols pertaining to personalites are developed,
> but that is a test done by compilation, so it should be 
> unproblematical.

I have checked in this method now.  I actually have an unexelf.c that 
works
with exec-shield on now, but I have only tested it on Fedora Core 2.  It
is probably too risky to check it in this close to a release.

	Jan D.

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

[Richard Stallman]

    I have checked in this method now.  I actually have an unexelf.c that 
    works
    with exec-shield on now, but I have only tested it on Fedora Core 2.  It
    is probably too risky to check it in this close to a release.

I think we can.  It should get enough testing.  It's not as if there
were a dozen completely different systems that this had to support.
There is only one, with just a few variants that might raise this case.

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

[Camm Maguire]

Greetings!

"Jan D." <jan.h.d@swipnet.se> writes:

> >> Another idea: can `main' contain code to move its heap address to the
> >> desired place, at startup?
> >
> >     No, as the desired place is not a mapped memory region, you can
> > not write
> >     there.
> >
> > How about mapping a memory region at the desired place, then
> > putting the heap address there?
> 
> It could work, but sounds tricky, you would have to mmap exactly
> between BSS and the heap.  It is possible that the kernel could
> reject such a request.  I haven't tested it though.
> 
> >       But we could do as described by Camm Maguire, check if the
> > heap is not
> >     at the correct place at temacs startup, and if it is not, call
> >     personality(LINUX32) and exec() temacs again.
> >
> > That also seems like a good method, perhaps better.  It would require
> > testing whether the symbols pertaining to personalites are developed,
> > but that is a test done by compilation, so it should be
> > unproblematical.
> 
> I have checked in this method now.  I actually have an unexelf.c that
> works
> with exec-shield on now, but I have only tested it on Fedora Core 2.  It
> is probably too risky to check it in this close to a release.
> 

I'd be interested to see your unexelf.c patch.

Take care,

> 	Jan D.
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

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

[Jan D.]

>
> I'd be interested to see your unexelf.c patch.
>
> Take care,
>

Duh, turns out that I had exec-shield-randomize set to 0, so it is not
working.  I'm suspending this work for now.

	Jan D.

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

[Camm Maguire]

Greetings!

"Jan D." <jan.h.d@swipnet.se> writes:

> >
> > I'd be interested to see your unexelf.c patch.
> >
> > Take care,
> >
> 
> Duh, turns out that I had exec-shield-randomize set to 0, so it is not
> working.  I'm suspending this work for now.
> 

OK, should you ever pick it up again, please drop me a note.

Take care,

> 	Jan D.
> 
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

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

[Richard Stallman]

    Duh, turns out that I had exec-shield-randomize set to 0, so it is not
    working.  I'm suspending this work for now.

Suspending what, precisely?

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

[Jan D.]

>     Duh, turns out that I had exec-shield-randomize set to 0, so it is 
> not
>     working.  I'm suspending this work for now.
>
> Suspending what, precisely?

I will stop working on getting unexec to dump correctly with a 
randomized
heap start address until after I've done more urgent things.  For 
example
getting the GTK scroll bars to behave, as this is in admin/FOR-RELEASE.

	Jan D.

other unexec problems

[Camm Maguire]

Greetings!  Two other unexec issues I thought I'd mention in case they
trigger any ideas:

1) Unexec'ed (elf) images cannot (apparently) be prelinked
http://bugs.debian.org/262891
http://bugs.debian.org/262890

2) Unexec'ed images on powerpc cannot be reliably stripped
http://bugs.debian.org/210809

Any ideas, or even just confirmations/refutations with emacs, most
appreciated.
-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: other unexec problems

[Jan D.]

> Greetings!  Two other unexec issues I thought I'd mention in case they
> trigger any ideas:
>
> 1) Unexec'ed (elf) images cannot (apparently) be prelinked
> http://bugs.debian.org/262891
> http://bugs.debian.org/262890
>
> 2) Unexec'ed images on powerpc cannot be reliably stripped
> http://bugs.debian.org/210809
>
> Any ideas, or even just confirmations/refutations with emacs, most
> appreciated.

I'd expect emacs to have the same problems as described in the two bugs 
above, but I have not checked.  The trend seems to go to more 
complicated binary file formats, and more types of file formats.  This 
suggests to me that it might be a good time to rethink the whole unexec 
approach.  There must be some other more platform neutral way to save 
and restore state.

	Jan D.

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

[Richard Stallman]

    and so emacs refuses to configure -- but if disable this test by doing:

       $ make ac_cv_file__proc_sys_kernel_exec_shield=no

    Then Emacs configures and dumps just fine, despite not using `setarch'.

It should be possible to compile a simple program that links with
unexec and see if it succeeds in dumping, as the way to determine
whether setarch is really needed.