Kernel related (?) user space crash at ARM11 MPCore
Jamie Lokier
jamie at shareable.org
Mon Sep 21 05:41:45 EDT 2009
Russell King - ARM Linux wrote:
> On Mon, Sep 21, 2009 at 09:31:09AM +0100, Jamie Lokier wrote:
> > I'm not able to tell from this thread, and I don't have the hardware
> > to test either:
> >
> > I have some userspace ARM code which modifies instructions and data
> > used by those instructions in a few pages, using mprotect() to make
> > them writable, modify, and make them PROT_READ|PROT_EXEC again.
> >
> > There is no execution of the modified code _during_ the modification,
> > only afterwards.
>
> We've had a syscall to handle the cache issues to do with self
> modifying code - __ARM_NR_cacheflush. See the comments associated
> with 'cacheflush' in arch/arm/kernel/traps.c about how to use it.
> This is the situation which the syscall was designed to address back
> in the 1990s.
Understood already. Other archs have a similar call. My question was
multiple questions, specifically in response to this thread:
- Whether sys_cacheflush is necessary when doing mprotect RW->RX
after writing new code, or does the mprotect imply it (I presume
_mmap_ always does);
- If a kernel bug has been uncovered which makes sys_cacheflush
insufficient for that in some obscure case under discussion with
COW pages;
- Whether it is necessary if only the data words in a code+data
page are modified (similar to ELF PLT updates), in principle, and
- If the above answer is no, with only the data words written, the
bug under discussion, is sys_cacheflush necessary to work with
unfixed kernels?
Thanks,
-- Jamie
More information about the linux-arm-kernel
mailing list