Re: architecture paper draft

["Stephen C. Tweedie" <sct at redhat dot com>]

Hi,

On Thu, 2005-02-10 at 14:34, Frank Ch. Eigler wrote:

> Thank you for chiming in!  Can you confirm that it is unwise to assume
> that the only failure mode of code that Still Does That is a page fault
> (which may be able to catch).

No.  Like I said in the previous email, try it from an interrupt or from
code that already has a spinlock and you could freeze solid.  And try it
from code that holds a KM_USER_COPY kmap_atomic, and you can corrupt
data on 4g/4g.

On non-4g/4g i386, things are not likely to fall apart, since user-space
access is basically not any different to kernel-space access.  But on
4g/4g, or on other architectures which segment user and kernel space
more strongly, very bad things might happen if you copy*user at the
wrong time.

> Given that we do need to enable at least some user-space access from
> relatively unrestricted contexts, is there anything we can do safely?
> Like, for example, is there a function that can walk paging tables
> by hand

That's exactly what the 4g4g user-space access does, and it makes things
worse since you then have to spinlock the page tables, which is exactly
where so many of the problems come from.

> able to cleanly return in case of something odd (absent
> page, screwed-up table, ...)?  Something that might be slow, and
> succeed only some of the time, but at least is crash-proof?

All the code to do that assumes that it's being called from somewhere
where it is legal to do copy_*_user.  We already *do* catch all the
cases of pointers to unmapped areas etc. etc. in copy_*_user: the kernel
relies on that to return EFAULT if you pass a dodgy address to a
syscall.  It's the cases where _any_ copy_*_user is illegal that are the
problem.

> Alternately, is it the case that if our probe functions can conservatively
> assess that any user-space access is at the moment unsafe (in_interrupt())?

Checking for in_interrupt(), in_atomic() would certainly help.  I don't
think in_atomic() checks for spinlocks, though. 

Indeed, even that's not strong enough --- if the user access takes a
page fault, the fault handler may require a semaphore, which can
deadlock if there are certain other locks already held.

--Stephen