Kernel related (?) user space crash at ARM11 MPCore

[Catalin Marinas]

On Mon, 2009-09-21 at 23:33 +0100, Jamie Lokier wrote:
> Russell King - ARM Linux wrote:
> > 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