kernel virtual memory access (from app) does not generate segfault

Russell King - ARM Linux linux at arm.linux.org.uk
Tue Apr 20 18:41:08 EDT 2010


On Tue, Apr 20, 2010 at 11:31:06PM +0100, Jamie Lokier wrote:
> Russell King - ARM Linux wrote:
> > 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.

That'd be very disgusting if it ever happened.

> 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?

No - the first data fault will cause the pgd entry to be copied, and then
the subsequent data fault will be a permission fault.

The difference between instruction faults and data faults is that we
always interpret instruction faults on pre-ARMv6 CPUs as a 'translation
fault' rather than a permission fault since they can't tell us what the
problem was.



More information about the linux-arm-kernel mailing list