kernel virtual memory access (from app) does not generate segfault
Jamie Lokier
jamie at shareable.org
Tue Apr 20 18:31:06 EDT 2010
Russell King - ARM Linux wrote:
> On Tue, Apr 20, 2010 at 06:09:44PM +0100, Ben Dooks wrote:
> > On Tue, Apr 20, 2010 at 10:20:47PM +0800, anfei wrote:
> > > On Tue, Apr 20, 2010 at 11:27:40AM +0100, Dave P. Martin wrote:
> > > > > From: linux-arm-kernel-bounces at lists.infradead.org
> > > > > [mailto:linux-arm-kernel-bounces at lists.infradead.org] On
> > > > > Behalf Of Ben Dooks
> > > > > Your first example writes to an area, your second is
> > > > > execution. IIRC, this version of the ARM architecture equates
> > > > > read and execute permission and so you may actually have
> > > > > permission to read this area and thus execute code in it.
>
> User programs do not have permission to read kernel addresses. Trying to
> do so _should_ generate a permission fault.
>
> > probably best to get Russell's opinion.
>
> if (user_mode(regs))
> goto bad_area;
>
> should be sufficient, since userspace should not be accessing anything
> above TASK_SIZE, except for the exception page, which will always be
> mapped.
Those two lines look good to me, or alternatively change
if (addr < TASK_SIZE)
to
if (addr < TASK_SIZE || user_mode(regs))
which lead to the same SIGSEGV by a more complicated route. That will
continue to work if user-accessible pages are ever mapped using the
vmalloc lazy method. Currently not, and I'm sure if that's ever done
it will be noticed quickly :-)
But a possible NAK: What happens when the kernel does get/put_user()
on an address > TASK_SIZE with kernel-only mapping? user_mode()
returns 0, so the LDRT will loop in the kernel, won't it?
Reviewed-by: Jamie Lokier <jamie at shareable.org>
-- Jamie
More information about the linux-arm-kernel
mailing list