Kernel related (?) user space crash at ARM11 MPCore
Catalin Marinas
catalin.marinas at arm.com
Mon Sep 21 18:34:53 EDT 2009
Jamie Lokier wrote:
> Catalin Marinas wrote:
>> A possible scenario (though more code analysis is needed to be entirely
>> sure) with writing instructions and not calling sys_cacheflush():
>>
>> - application mmap's a file (shared mapping, otherwise the data written
>> to private mappings is lost when unmapping)
>> - app writes some instructions to text pages. We don't get CoW because
>> of the shared mapping but we don't get D-cache cleaning either
>> - app unmap's the page but the kernel keeps the physical page in its
>> page cache. The flush_cache_page() on non-aliasing VIPT doesn't do
>> anything on ARM
>> - app mmap's the page with PROT_READ|PROT_EXEC
>> - app executes from the page generating a prefetch abort. The kernel
>> finds the page in its page cache and maps it into user space, calling
>> update_mmu_cache(). However, the dirty bit isn't set (since the kernel
>> hasn't touched the page) and the lazy D-cache flushing in
>> update_mmu_cache isn't triggered, leaving the I-cache with old entries
>> directly from RAM.
>
> Why isn't the dirty bit set by the last step?
By dirty here I mean the PG_arch_1 bit set by flush_dcache_page() which
won't happen at step 2.
> The dirty bit must be set by the writes in the second step, otherwise
> how does the kernel know not to discard those writes under memory
> pressure?
That's another dirty bit (I think PG_dirty) but it isn't taken into
account by update_mmu_cache(). As I said, more in-depth code analysis
here is needed to be entirely sure.
> Btw, regarding "non-aliasing", it's pretty clear that it does alias
> the I-cache ;-),
We just refer to D-cache aliasing here.
> in much the same way as different addresses alias in
> the D-cache with an "aliasing" cache. That may well be a clue as to
> clean, systematic and sane way of ensuring all the cache ops are in
> all the right places.
We should indeed favour correctness but there may be some corner cases
which aren't used anyway, so we shouldn't penalise normal usage.
--
Catalin
More information about the linux-arm-kernel
mailing list