>> # 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
