Kernel related (?) user space crash at ARM11 MPCore

[Jamie Lokier]

Russell King - ARM Linux wrote:
> On Mon, Sep 21, 2009 at 11:07:51AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Sep 21, 2009 at 10:44:23AM +0100, Catalin Marinas wrote:
> > > I would still call this I-D cache coherency issue since the two caches
> > > have a different view of the RAM but I agree that the D-cache is the one
> > > holding the data (with a slight chance for the I-cache not to be in sync
> > > with main RAM, though we could treat it separately).
> > > 
> > > We can sort out the D-cache issue with your approach for cleaning it in
> > > the copy_user_highpage() function, but, as I said, we affect the
> > > standard CoW mechanism for data pages quite a lot.
> > 
> > Let me restate my approach more clearly:
> > 
> > 1. Remember that a VMA has been executable.
> > 2. Only do the additional handing if the VMA has been executable.
> 
> Well, there's a problem with this approach.  Any binary which executes
> with read-implies-exec (in other words, the majority of those around)
> results in any region with read permission also getting exec permission.
> 
> 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.

PROT_READ implying PROT_READ|PROT_EXEC may be needed for historical
compatibility reasons, but PROT_READ|PROT_WRITE implying
PROT_READ|PROT_WRITE|PROT_EXEC - there might not be any code doing that.

I would guess (but it's just a guess) that the sort of people who
execute code from a PROT_WRITE segment would have known to set
PROT_EXEC, and the main cause for concern would be if there are
executables which have writable data immediately after the text
segment, in the same page, to save space in an executable.  Has that
happened?  Even that would be of no concern if that page is always
mapped PROT_EXEC by the loaders.

Hmm :/  Actually I'm quite surprised read-implies-exec is needed.

-- Jamie