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 there any solution to test for effective permission except by trying to execute something on the stack (thus crashing the program on a successful test...)? Arjan van de Ven also wrote in other mails: > the "nx" shows that if you configure your kernel correctly (enable > PAE) that you indeed have a non-executable capability, which will > apply to the stack (and afaik the heap too) [...] > enable > CONFIG_HIGHMEM64G=y > and you're all set [...] > btw in case you didn't realize this; your processor is also 64 it > capable, just use any x86-64 distribution on it ;) Thanks for the tips! 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/
Re: Executability of the stack
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 segment). this is not per se true, it depends on the capabilities of your 32 bit x86 processor. # 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. Is there any reason for this situation? the alternative (showing effective permission) is equally confusing; apps would see permissions they didn't set... Why not show both. "intent" and "effective". - 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/
Re: Executability of the stack
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 recent: > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm the "nx" shows that if you configure your kernel correctly (enable PAE) that you indeed have a non-executable capability, which will apply to the stack (and afaik the heap too) > > 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. it's debatable what the file means; the maps file shows software permissions currently not hardware enforced permissions. The "problem" is that if you show software permissions... it's harder to see the kernels view (vma's etc). I don't think there's a perfect answer. It gets even more complex if you have something like execshield in use; where the stack and heap are non-executable, unless you get a "higher" executable mapping. In that case, the appearance of such a higher mapping would change the visual mapping of other mappings. Outright confusing as well :) > > >> 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. your cpu has this bit, you just didn't turn it on ;( > > 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. enable CONFIG_HIGHMEM64G=y and you're all set. Greetings, Arjan van de Ven -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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/
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 : 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/
Re: Executability of the stack
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 true, it depends on the capabilities of your 32 bit x86 processor. > # 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. > Is there any reason for this situation? the alternative (showing effective permission) is equally confusing; apps would see permissions they didn't set... > 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. 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) Greetings, Arjan van de Ven - 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/
Re: Executability of the stack
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 true, it depends on the capabilities of your 32 bit x86 processor. # 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. Is there any reason for this situation? the alternative (showing effective permission) is equally confusing; apps would see permissions they didn't set... 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. 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) Greetings, Arjan van de Ven - 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/
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 : 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/
Re: Executability of the stack
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 recent: mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm the nx shows that if you configure your kernel correctly (enable PAE) that you indeed have a non-executable capability, which will apply to the stack (and afaik the heap too) 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. it's debatable what the file means; the maps file shows software permissions currently not hardware enforced permissions. The problem is that if you show software permissions... it's harder to see the kernels view (vma's etc). I don't think there's a perfect answer. It gets even more complex if you have something like execshield in use; where the stack and heap are non-executable, unless you get a higher executable mapping. In that case, the appearance of such a higher mapping would change the visual mapping of other mappings. Outright confusing as well :) 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. your cpu has this bit, you just didn't turn it on ;( 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. enable CONFIG_HIGHMEM64G=y and you're all set. Greetings, Arjan van de Ven -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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/
Re: Executability of the stack
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 segment). this is not per se true, it depends on the capabilities of your 32 bit x86 processor. # 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. Is there any reason for this situation? the alternative (showing effective permission) is equally confusing; apps would see permissions they didn't set... Why not show both. intent and effective. - 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/
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 there any solution to test for effective permission except by trying to execute something on the stack (thus crashing the program on a successful test...)? Arjan van de Ven also wrote in other mails: the nx shows that if you configure your kernel correctly (enable PAE) that you indeed have a non-executable capability, which will apply to the stack (and afaik the heap too) [...] enable CONFIG_HIGHMEM64G=y and you're all set [...] btw in case you didn't realize this; your processor is also 64 it capable, just use any x86-64 distribution on it ;) Thanks for the tips! 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/
