Messages in this thread | | | Date | Thu, 1 Jul 2004 23:40:16 +0100 | From | Jamie Lokier <> | Subject | Comparing PROT_EXEC-only pages on different CPUs |
| |
Alpha and IA64 are the only Linux architecture where PROT_EXEC by itself results in exec-only pages. Interestingly, the hardware of some other architectures _could_ implement exec-only pages, but they chose not to:
The PA-RISC pgtable.h says:
"We could have an execute only page using "gateway - promote to priv level 3", but that is kind of silly. So, the way things are defined now, we must always have read permission for pages with execute permission. For the fun of it we'll go ahead and support write only pages."
Richard Curnow working on the SH64 port says:
"Although the hardware is capable of distinguish R and X, the kernel always allows R if X is specified to mmap(). This is for 2 reasons :
1. jump tables for switch() get embedded into the code in 32-bit (SHmedia) mode 2. constant pools embedded in the code in 16-bit (SHcompact, i.e. SH-4 compatible) mode
so in practice an exec-only page is pretty useless to a typical userland program."
Richard raises an interesting point: exec-only pages are useless if the code needs to read jump tables and constant pools. It seems very likely Alpha and IA64 have these.
The point is: should the automatic addition of read permission be kernel policy (as on SH64 and PA-RISC), or should it be for userspace policy to get right as real code probably needs it (as on Alpha and IA64)?
Does anyone think there's a "right" behaviour which current or future Linux ports should try to conform to? Should any of the current ones be changed?
I'm just making sure all 4 know about each others behaviour before I wash my hands of this observation. :)
Cheers, -- Jamie - 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/
| |