Kernel related (?) user space crash at ARM11 MPCore

[Catalin Marinas]

On Mon, 2009-09-21 at 22:38 +0100, 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.

Some idea (not tested) - we keep XN always set even if the mapping has
PROT_EXEC. We then handle the prefetch abort and with the IFSR patches
from Kirill we can detect the permission fault and clear the XN bit
while also cleaning the D-cache, maybe via update_mmu_cache() or
directly in __do_page_fault().

Most text pages are handled via a prefetch abort anyway, so we don't
have any performance penalty here. For the read-implies-exec pages or
the dynamic linker case, we have an additional prefetch abort but that's
much faster than either flush_cache_range() or copy_to_user_highpage()
patches.

We may need an additional pte bit or just reuse L_PTE_EXEC.

Yet another idea - add a generic flush_cache_range_for_mprotect()
function with a specific implementation for ARM (called via
change_protection).

-- 
Catalin