Re: Executability of the stack

2006-12-14 Thread Franck Pommereau
Arjan van de Ven wrote: >> Why not show both. >> "intent" and "effective". > > that would change the file format .. which is used by apps today already > (including glibc) So, what about having another file, say /proc/self/emaps (effective maps) that would display how things are really set.

Re: Executability of the stack

2006-12-14 Thread James Courtier-Dutton
Arjan van de Ven wrote: On Thu, 2006-12-14 at 10:26 +0100, Franck Pommereau wrote: Dear Linux developers, I recently discovered that the Linux kernel on 32 bits x86 processors reports the stack as being non-executable while it is actually executable (because located in the same memory

Re: Executability of the stack

2006-12-14 Thread Arjan van de Ven
On Thu, 2006-12-14 at 13:07 +0100, Franck Pommereau wrote: > >> # grep maps /proc/self/maps > >> bfce8000-bfcfe000 rw-p bfce8000 00:00 0 [stack] > > > > this shows that the *intent* is to have it non-executable. > > Not all x86 processors can enforce this. All modern ones do. > > Mine

Re: Executability of the stack

2006-12-14 Thread Franck Pommereau
>> # grep maps /proc/self/maps >> bfce8000-bfcfe000 rw-p bfce8000 00:00 0 [stack] > > this shows that the *intent* is to have it non-executable. > Not all x86 processors can enforce this. All modern ones do. Mine is quite recent: # cat /proc/cpuinfo processor : 0 vendor_id

Re: Executability of the stack

2006-12-14 Thread Arjan van de Ven
On Thu, 2006-12-14 at 10:26 +0100, Franck Pommereau wrote: > Dear Linux developers, > > I recently discovered that the Linux kernel on 32 bits x86 processors > reports the stack as being non-executable while it is actually > executable (because located in the same memory segment). this is not

Executability of the stack

2006-12-14 Thread Franck Pommereau
Dear Linux developers, I recently discovered that the Linux kernel on 32 bits x86 processors reports the stack as being non-executable while it is actually executable (because located in the same memory segment). # grep maps /proc/self/maps bfce8000-bfcfe000 rw-p bfce8000 00:00 0

Executability of the stack

2006-12-14 Thread Franck Pommereau
Dear Linux developers, I recently discovered that the Linux kernel on 32 bits x86 processors reports the stack as being non-executable while it is actually executable (because located in the same memory segment). # grep maps /proc/self/maps bfce8000-bfcfe000 rw-p bfce8000 00:00 0

Re: Executability of the stack

2006-12-14 Thread Arjan van de Ven
On Thu, 2006-12-14 at 10:26 +0100, Franck Pommereau wrote: Dear Linux developers, I recently discovered that the Linux kernel on 32 bits x86 processors reports the stack as being non-executable while it is actually executable (because located in the same memory segment). this is not per se

Re: Executability of the stack

2006-12-14 Thread Franck Pommereau
# grep maps /proc/self/maps bfce8000-bfcfe000 rw-p bfce8000 00:00 0 [stack] this shows that the *intent* is to have it non-executable. Not all x86 processors can enforce this. All modern ones do. Mine is quite recent: # cat /proc/cpuinfo processor : 0 vendor_id :

Re: Executability of the stack

2006-12-14 Thread Arjan van de Ven
On Thu, 2006-12-14 at 13:07 +0100, Franck Pommereau wrote: # grep maps /proc/self/maps bfce8000-bfcfe000 rw-p bfce8000 00:00 0 [stack] this shows that the *intent* is to have it non-executable. Not all x86 processors can enforce this. All modern ones do. Mine is quite

Re: Executability of the stack

2006-12-14 Thread James Courtier-Dutton
Arjan van de Ven wrote: On Thu, 2006-12-14 at 10:26 +0100, Franck Pommereau wrote: Dear Linux developers, I recently discovered that the Linux kernel on 32 bits x86 processors reports the stack as being non-executable while it is actually executable (because located in the same memory

Re: Executability of the stack

2006-12-14 Thread Franck Pommereau
Arjan van de Ven wrote: Why not show both. intent and effective. that would change the file format .. which is used by apps today already (including glibc) So, what about having another file, say /proc/self/emaps (effective maps) that would display how things are really set. Currently, is