Re: Executability of the stack

[Franck Pommereau <pommereau@univ-paris12.fr>]

>> # 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       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz
stepping        : 6
cpu MHz         : 1000.000
cache size      : 4096 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc up pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 3996.23

> the alternative (showing effective permission) is equally confusing;
> apps would see permissions they didn't set...

Indeed, both are confusing (the other way is having permission that you
do not see). But which one is the most dangerous from a security point
of view? For me it is believing that you're protected while you're not.

>> Maybe it comes from sharing source code for 64 bits and 32 bits
>> architectures but if so, it should be possible (and highly desirable) to
>> treat 32 bits differently.
> 
> it's not a "32 bit" thing, it's an "older processors don't, newer ones
> do" thing.

I've read that 64 bit processors have an execute bit at the page level
while 32 bit ones do not (only at the segment level). I didn't know that
newer 31 bit CPUs did have this bit.

> Can you paste your /proc/cpuinfo file here ? Maybe you have a processor
> with the capability but just haven't enabled it (either in the bios or
> in the kernel config)

I'd be happy to know how to enable it.

Thanks for your help.
Franck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/