Re: Executability of the stack

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

>> # 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

Executability of the stack

bits and 32 bits architectures but if so, it should be possible (and highly desirable) to treat 32 bits differently. Best regards, Franck Pommereau --- Below is the output from the ver_linux script

Executability of the stack

bits and 32 bits architectures but if so, it should be possible (and highly desirable) to treat 32 bits differently. Best regards, Franck Pommereau --- Below is the output from the ver_linux script

Re: Executability of the stack

# 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

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