Re: Finding user/kernel pointer bugs [no html]

[viro]

On Thu, Jun 10, 2004 at 07:46:40AM -0700, Linus Torvalds wrote:
 
> The only way to fix the second case is to split the structure up - which
> is usually a good idea _anyway_, but which can sometimes be pretty 
> painful. Al has done some of them. The really painful one is "struct 
> iovec", which seems to be used in this capacity a fair amount.

iovec is, I'm afraid, hopeless.  E.g. TCP code does tons of work before
it even looks at the data; doing two versions (for kernel and userland
pointers) is too ridiculous for words.  So kernel users (== RPC of all
sorts) either do it from kernel threads or use set_fs() around sock_sendmsg().
That would be a convenient chokepoint, if we would e.g. always pass a
single-element arrays - we could add kernel_sendmsg() that would take
a _kernel_ pointer + length + flags, force them into iovec, call set_fs()
and pass that stuff to sock_sendmsg() (and similar for recepients).
Unfortunately, it doesn't work that way - there are places that pass
multi-element arrays.  And there are guys who don't need set_fs() since
they are in kernel threads.

It might be possible to clean up, but I would stay away from that mess for
a while.  Non-networking code is simple - it's almost always either only
kernel or only userland.  XFS is a major offender in that respect, but
that's the matter of SGI politics and not much more, AFAICS.

Note that we get very real fuckups with that - e.g. econet-over-ethernet
slaps a kernel chunk of data in front of userland ones, does verify_area()
on the latter, calls set_fs() and sends the mixed vector to UDP code.
It breaks big way on a bunch of platforms, obviously...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/