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?

quoted text
> >> That is why I'm suggesting using an in-kernel linearizer.
> > 
> > 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/