Messages in this thread |  | | Date | Sat, 19 May 2001 20:26:20 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [RFD w/info-PATCH] device arguments from lookup, partion code |
| |
On Sat, 19 May 2001, Richard Gooch wrote: > > Matthew Wilcox writes: > > On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote: > > > The transaction(2) syscall can be just as easily abused as ioctl(2) in > > > this respect. > > > > But read() and write() cannot. > > Sure they can. I can pass a pointer to a structure to either of them.
You're missing the point.
It's ok to do "read()/write()" on structures. In fact, people do that all the time (and then they complain about the file not being portable ;)
The problem with ioctl is that not only are people passing ioctl's pointers to structures, but: - they're not telling how big the structure is - the structure can have pointers to other places - sometimes it modifies the structure passed in
None of which are "network-nice". Basically, ioctl() is historically used as a "pass any crap into driver xxxx, and the driver - and ONLY the driver - will know what to do with it".
And when _only_ a driver knows what the arguments mean, upper layers can't encapsulate them. Upper layers cannot make a packet of the argument and send it over the network to another machine. Upper layers cannot do sanity-checking on things like "is this argument a valid pointer". Which means, for example, that not only can you not send the ioctl arguments anywhere, but ioctl's have also historically been a hot-bed of bugs.
Example traditional ioctl bugs: use kernel pointers to access the argument (because it just happens to work on x86, never mind the fact that if the argument is bad you'll get a kernel oops and/or a serious security error). Other example: different drivers/f ilesystems implementing the same ioctl, but disagreeing on what the argument means (is it a pointer to an integer argument, or the integer itself?).
Now, the advantage of using read()/write() is (a) that it's unambiguous where the argument comes from and how big it is and (b) because of that the _psychology_ is different. You don't get into this "pass random crap around, let the kernel modify user data structures directly" mentality.
And psychology is important.
Linus
- 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/
|  |