On Mon, 2009-09-21 at 23:33 +0100, Jamie Lokier wrote:

Russell King - ARM Linux wrote:

quoted

So, mprotect(rw) actually ends up as mprotect(rwx), which means that
effectively _all_ VMAs have been executable.

This approach won't work as well as I'd hope, since this means every
COW fault ends up triggering the cache flush.

However, the same problem affects Catalin's approach too - with these
binaries, every VMA has VM_EXEC set, which means every VMA gets the
cache flushing treatment whenever flush_cache_range() is called.

This is a nasty problem to solve...

Would it be so harmful if mprotect(rw) were treated as mprotect(rw),
while mprotect(r) is treated as mprotect(rx)?  Sure, someone _could_
exec from rw pages, but they _should not_ be doing so if they haven't
set PROT_EXEC.

For OABI, I think we rely on executable user stack for signal handling
and the arm_elf_read_implies_exec() always returns 1. There are also
tools like like this - http://linux.die.net/man/8/execstack - or maybe
the toolchain setting the PT_GNU_STACK which would also set the
read_implies_exec for the stack. And the stack must be writable.

-- 
Catalin