On Thu, 28 Aug 2008, H. Peter Anvin wrote:

quoted text
> Miklos Szeredi wrote:

> > On Thu, 28 Aug 2008, H. Peter Anvin wrote:

> >> This is *hard* to get right, and we screw this up in the kernel with

> >> painful regularity.  The throught of having user-space processes, which

> >> don't have access to the kernel locking primitives and functions like

> >> copy_from_user() dealing with this stuff scares me crazy.

> >

> > What issues exactly are you thinking of?

>

> Memory changing underneath you.  It can be dealt with by very careful

> sequencing only.

That's just handwaving.  Apps don't normally change memory under

system call arguments.  Or if they do the only thing we ever guarantee

is that the thing won't blow up in a big fireball.
I don't see how getting the data from userspace is different from

doing the same in the kernel.  Care to explain?
> >> That is why I'm suggesting using an in-kernel linearizer.

quoted text
> >

> > Lots of complexity, ugh...  Even Tejun's current scheme is better IMO.

>

> And then you get *no* privilege separation, for one thing, so why even

> bother doing it in userspace?

And with ioctls (at least if the filesystem supplies the linearizer

instructions) you simply _cannot_ get proper privilege separation.

Generic ioctl support will always be a privileged thing.
Alternatively we can restrict ioctls.  Most ioctls conform to some

convention for encoding the format (size/in/out) in the command, no?
Miklos

--

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/