Re: Executability of the stack
- From: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
- Date: Thu, 14 Dec 2006 13:19:07 +0100
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- [PATCH] Clarify i386/Kconfig explanation of the HIGHMEM config options
- From: Theodore Tso
- [PATCH] Clarify i386/Kconfig explanation of the HIGHMEM config options
- References:
- Executability of the stack
- From: Franck Pommereau
- Re: Executability of the stack
- From: Arjan van de Ven
- Re: Executability of the stack
- From: Franck Pommereau
- Executability of the stack
- Prev by Date: Re: [GIT PATCH] more Driver core patches for 2.6.19
- Next by Date: [PATCH] slab: fix kmem_ptr_validate prototype
- Previous by thread: Re: Executability of the stack
- Next by thread: [PATCH] Clarify i386/Kconfig explanation of the HIGHMEM config options
- Index(es):
Relevant Pages
|
