Needed for the release

Needed for the release

[Richard Stallman]

We need someone to fix the problem that unexelf.c has in dumping with
some recent Linux versions used by Red Hat GNU/Linux.  This is a very
serious problem.  Would someone please work on it?

Please write to me if you start to work on this.

Re: Needed for the release

[Masatake YAMATO]

> We need someone to fix the problem that unexelf.c has in dumping with
> some recent Linux versions used by Red Hat GNU/Linux.  This is a very
> serious problem.  Would someone please work on it?

How can I reproduce the problem?
Could you give me a pointer to know more? 

Re: Needed for the release

[Richard Stallman]

What I remember is that Red Hat enables a feature in Linux that (I
believe) uses the address space differently.  unexelf.c doesn't handle
it right.

I don't remember the name of the feature, but I'm sure other people
on this list remember the name.

Re: Needed for the release

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> What I remember is that Red Hat enables a feature in Linux that (I
> believe) uses the address space differently.  unexelf.c doesn't handle
> it right.
>
> I don't remember the name of the feature, but I'm sure other people
> on this list remember the name.

exec_shield is one such feature, and newer kernels use something like,
uh, /proc/sys/vm/randomize_... (I don't remember the particular name
right now and don't have a Fedora active).  The latter loaded
executables' memory segments into randomized locations to make buffer
overflow attacks less predictable.

exec_shield could be gotten around with using
setarch i386 make
and configure does that already IIRC.  But the address space
randomization was prohibiting the dumping even with the setarch
command.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Needed for the release

[jhd]

11 jun 2005 kl. 01.34 skrev David Kastrup:

> Richard Stallman <rms@gnu.org> writes:
>
>
>> What I remember is that Red Hat enables a feature in Linux that (I
>> believe) uses the address space differently.  unexelf.c doesn't  
>> handle
>> it right.
>>
>> I don't remember the name of the feature, but I'm sure other people
>> on this list remember the name.
>>
>
> exec_shield is one such feature, and newer kernels use something like,
> uh, /proc/sys/vm/randomize_... (I don't remember the particular name
> right now and don't have a Fedora active).  The latter loaded
> executables' memory segments into randomized locations to make buffer
> overflow attacks less predictable.
>
> exec_shield could be gotten around with using
> setarch i386 make
> and configure does that already IIRC.  But the address space
> randomization was prohibiting the dumping even with the setarch
> command.

There is some info in etc/PROBLEMS, and some information here:

http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
http://people.redhat.com/drepper/nonselsec.pdf

And if you search for Exec-shield here:
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release- 
notes/as-x86/RELEASE-NOTES-U3-x86-en.html


They don't describe the new randomizing features though.

     Jan D.

Re: Needed for the release

[Richard Stallman]

    exec_shield could be gotten around with using
    setarch i386 make
    and configure does that already IIRC.  But the address space
    randomization was prohibiting the dumping even with the setarch
    command.

It may be possible for unexec to get around that problem by writing a
suitable kind of file that won't allow the randomization.  It might
need to deal with the effects of randomization at the time temacs was
run, but this might not be impossible.  One would need to study the
details of the feature.

Masatake-san, would you like to study the details and see?

    They don't describe the new randomizing features though.

If we can't find any documentation of these features,
we can try asking people in Red Hat to describe them.
I have some contacts to ask.

Another idea is to arrange to use CANNOT_DUMP
on those systems.

Re: Needed for the release

[Masatake YAMATO]

>     exec_shield could be gotten around with using
>     setarch i386 make
>     and configure does that already IIRC.  But the address space
>     randomization was prohibiting the dumping even with the setarch
>     command.
> 
> It may be possible for unexec to get around that problem by writing a
> suitable kind of file that won't allow the randomization.  It might
> need to deal with the effects of randomization at the time temacs was
> run, but this might not be impossible.  One would need to study the
> details of the feature.
> 
> Masatake-san, would you like to study the details and see?
> 
>     They don't describe the new randomizing features though.
> 
> If we can't find any documentation of these features,
> we can try asking people in Red Hat to describe them.
> I have some contacts to ask.

I can do it by myself. I'm at Red hat:-)
Give me time.

Masatake

Re: Needed for the release

[Michael Welsh Duggan]

Masatake YAMATO <jet@gyve.org> writes:

>>     exec_shield could be gotten around with using
>>     setarch i386 make
>>     and configure does that already IIRC.  But the address space
>>     randomization was prohibiting the dumping even with the setarch
>>     command.
>> 
>> It may be possible for unexec to get around that problem by writing a
>> suitable kind of file that won't allow the randomization.  It might
>> need to deal with the effects of randomization at the time temacs was
>> run, but this might not be impossible.  One would need to study the
>> details of the feature.
>> 
>> Masatake-san, would you like to study the details and see?
>> 
>>     They don't describe the new randomizing features though.
>> 
>> If we can't find any documentation of these features,
>> we can try asking people in Red Hat to describe them.
>> I have some contacts to ask.
>
> I can do it by myself. I'm at Red hat:-)
> Give me time.

I found the following which might help:

http://kernel.org/pub/linux/kernel/people/arjan/randomize/

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

Re: Needed for the release

[Masatake YAMATO]

Sorry to be late.

> Richard Stallman <rms@gnu.org> writes:
> 
> > What I remember is that Red Hat enables a feature in Linux that (I
> > believe) uses the address space differently.  unexelf.c doesn't handle
> > it right.
> >
> > I don't remember the name of the feature, but I'm sure other people
> > on this list remember the name.
> 
> exec_shield is one such feature, and newer kernels use something like,
> uh, /proc/sys/vm/randomize_... (I don't remember the particular name
> right now and don't have a Fedora active).  The latter loaded
> executables' memory segments into randomized locations to make buffer
> overflow attacks less predictable.
> 
> exec_shield could be gotten around with using
> setarch i386 make
> and configure does that already IIRC.  But the address space
> randomization was prohibiting the dumping even with the setarch
> command.

Could you tell me the kernel version or the OS version?

I'm using Fedora core 1 and Fedora core 3.
I cannot reproduce the problem on the platforms.

Re: Needed for the release

[Masatake YAMATO]

> > Richard Stallman <rms@gnu.org> writes:
> > 
> > > What I remember is that Red Hat enables a feature in Linux that (I
> > > believe) uses the address space differently.  unexelf.c doesn't handle
> > > it right.
> > >
> > > I don't remember the name of the feature, but I'm sure other people
> > > on this list remember the name.
> > 
> > exec_shield is one such feature, and newer kernels use something like,
> > uh, /proc/sys/vm/randomize_... (I don't remember the particular name
> > right now and don't have a Fedora active).  The latter loaded
> > executables' memory segments into randomized locations to make buffer
> > overflow attacks less predictable.
> > 
> > exec_shield could be gotten around with using
> > setarch i386 make
> > and configure does that already IIRC.  But the address space
> > randomization was prohibiting the dumping even with the setarch
> > command.
> 
> Could you tell me the kernel version or the OS version?

What I'd like to say is I cannot reproduce the problem.
Emacs can be built fine on my computers.

Re: Needed for the release

[David Kastrup]

Masatake YAMATO <jet@gyve.org> writes:

> Sorry to be late.
>
>> exec_shield is one such feature, and newer kernels use something
>> like, uh, /proc/sys/vm/randomize_... (I don't remember the
>> particular name right now and don't have a Fedora active).  The
>> latter loaded executables' memory segments into randomized
>> locations to make buffer overflow attacks less predictable.
>> 
>> exec_shield could be gotten around with using
>> setarch i386 make
>> and configure does that already IIRC.  But the address space
>> randomization was prohibiting the dumping even with the setarch
>> command.
>
> Could you tell me the kernel version or the OS version?
>
> I'm using Fedora core 1 and Fedora core 3.
> I cannot reproduce the problem on the platforms.

It was introduced some time after Fedora core 3 in their development
sources.  I switched to Ubuntu a short time after that.  It is
possible that the feature did not make it switched on by default into
the final FC4 release, but I can't tell since I stopped updating it
after that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Needed for the release

[jhd]

> Masatake YAMATO <jet@gyve.org> writes:
>
>
>> Sorry to be late.
>>
>>
>>> exec_shield is one such feature, and newer kernels use something
>>> like, uh, /proc/sys/vm/randomize_... (I don't remember the
>>> particular name right now and don't have a Fedora active).  The
>>> latter loaded executables' memory segments into randomized
>>> locations to make buffer overflow attacks less predictable.
>>>
>>> exec_shield could be gotten around with using
>>> setarch i386 make
>>> and configure does that already IIRC.  But the address space
>>> randomization was prohibiting the dumping even with the setarch
>>> command.
>>>
>>
>> Could you tell me the kernel version or the OS version?
>>
>> I'm using Fedora core 1 and Fedora core 3.
>> I cannot reproduce the problem on the platforms.
>>
>
> It was introduced some time after Fedora core 3 in their development
> sources.  I switched to Ubuntu a short time after that.  It is
> possible that the feature did not make it switched on by default into
> the final FC4 release, but I can't tell since I stopped updating it
> after that.


If exec-shield is disabled or if the workaround in emacs.c works you  
won't see any problems.  But the workaround is to set personality to  
PER_LINUX32 and that may have other problems.  For example, does it  
work on a 64-bit system?  What about non-x86 architectures?  Does  
setting PER_LINUX32 have other side effects?

Ideally unexec should handle the case where heap and bss is not next  
to each other, and then this workaround can be removed.

     Jan D.

Re: Needed for the release

[Richard Stallman]

    Ideally unexec should handle the case where heap and bss is not next  
    to each other, and then this workaround can be removed.

Yes, that's the task that we need for the release, for
the sake of exec-shield.

But we also need something done to deal with the randomization feature.

Re: Needed for the release

[Dan Nicolaescu]

Masatake YAMATO <jet@gyve.org> writes:

  > Sorry to be late.
  > 
  > > Richard Stallman <rms@gnu.org> writes:
  > > 
  > > > What I remember is that Red Hat enables a feature in Linux that (I
  > > > believe) uses the address space differently.  unexelf.c doesn't handle
  > > > it right.
  > > >
  > > > I don't remember the name of the feature, but I'm sure other people
  > > > on this list remember the name.
  > > 
  > > exec_shield is one such feature, and newer kernels use something like,
  > > uh, /proc/sys/vm/randomize_... (I don't remember the particular name
  > > right now and don't have a Fedora active).  The latter loaded
  > > executables' memory segments into randomized locations to make buffer
  > > overflow attacks less predictable.
  > > 
  > > exec_shield could be gotten around with using
  > > setarch i386 make
  > > and configure does that already IIRC.  But the address space
  > > randomization was prohibiting the dumping even with the setarch
  > > command.
  > 
  > Could you tell me the kernel version or the OS version?
  > 
  > I'm using Fedora core 1 and Fedora core 3.
  > I cannot reproduce the problem on the platforms.

The problem occurs in Fedora Core 4.
On a FC4 system:
echo 0 > /proc/sys/kernel/randomize_va_space
is required in order to be able to dump Emacs.

Re: Needed for the release

[Masatake YAMATO]

> Masatake YAMATO <jet@gyve.org> writes:
> 
>   > Sorry to be late.
>   > 
>   > > Richard Stallman <rms@gnu.org> writes:
>   > > 
>   > > > What I remember is that Red Hat enables a feature in Linux that (I
>   > > > believe) uses the address space differently.  unexelf.c doesn't handle
>   > > > it right.
>   > > >
>   > > > I don't remember the name of the feature, but I'm sure other people
>   > > > on this list remember the name.
>   > > 
>   > > exec_shield is one such feature, and newer kernels use something like,
>   > > uh, /proc/sys/vm/randomize_... (I don't remember the particular name
>   > > right now and don't have a Fedora active).  The latter loaded
>   > > executables' memory segments into randomized locations to make buffer
>   > > overflow attacks less predictable.
>   > > 
>   > > exec_shield could be gotten around with using
>   > > setarch i386 make
>   > > and configure does that already IIRC.  But the address space
>   > > randomization was prohibiting the dumping even with the setarch
>   > > command.
>   > 
>   > Could you tell me the kernel version or the OS version?
>   > 
>   > I'm using Fedora core 1 and Fedora core 3.
>   > I cannot reproduce the problem on the platforms.
> 
> The problem occurs in Fedora Core 4.
> On a FC4 system:
> echo 0 > /proc/sys/kernel/randomize_va_space
> is required in order to be able to dump Emacs.

Thank you. I'll update my FC3 pc.

Masatake

Re: Needed for the release

[James Cloos]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> The problem occurs in Fedora Core 4.  On a FC4 system:
Dan> echo 0 >/proc/sys/kernel/randomize_va_space is required
Dan> in order to be able to dump Emacs.

I've not had any problems dumping emacs with Linus' and Andrew's
recent kernels, which default to randomize_va_space=1.  It has
to be more than just that.  

The laptop is booted into 2.6.12-rc4-mm2 right now, and I just
updated a few hours ago.

Unless rh's patch to add randomize_va_space is different that what
Linus merged....

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com>