[RFC PATCH v4] ARM: uprobes xol write directly to userspace

David Miller davem at davemloft.net
Wed Apr 16 14:21:53 PDT 2014


From: David Long <dave.long at linaro.org>
Date: Wed, 16 Apr 2014 16:24:18 -0400

> On 04/16/14 15:37, David Miller wrote:
>> From: Oleg Nesterov <oleg at redhat.com>
>> Date: Wed, 16 Apr 2014 21:18:25 +0200
>> 
>>> The last question... area->page = alloc_page(GFP_HIGHUSER), and I am
>>> not sure that arch/arm/mm/highmem.c:kmap_atomic() can't break the
>>> aliasing, __fix_to_virt() in this case will use the same (per-cpu) idx.
>>>
>>> Looks like, __kunmap_atomic()->__cpuc_flush_dcache_area() should take
>>> care, but could you please ack/nack my understanding?
>> 
>> Good point, it might therefore make sense to use a low-mem page.
>> 
> 
> The following test code seems to have the same problems with stale user
> icache.  It works if I put the dcache flush back in.  Am I missing
> something?

Weird, if we store to the kernel side it should be just a matter of
clearing the I-cache out.  There should be no D-cache aliasing
whatsoever.  Maybe you could print out area->vaddr and
page_to_virt(area->page) so we can see if area->vaddr is choosen
correctly?

Although I notice that flush_cache_user_range() on ARM flushes both D
and I caches.  And I think that's what userspace ends up triggering
when it uses the system call that exists to support self-modifying and
JIT code generators.

An ARM expert will have to chime in...



More information about the linux-arm-kernel mailing list