Re: [PARPORT] Buffer read/write verification


David Cambell (campbell@gear.torque.net)
Fri, 19 Mar 1999 08:11:01 -0500 (EST)


> Wondered what the opinions were on the fact that parport, and other drivers no
> doubt, always assume they are returning data to user-space. Hence they verify
> whether the data buffer is readable or writable.

Not always, SCSI style drivers leave the buffer management to the mid-level
driver.

> It appears that validating storage as well as the __get_user()/__put_user type
> routines are designed for calls from user-space only. It seems unnecessarily
> restrictive for calls from drivers and somewhat pointless. Drivers calling
> drivers are penalised by having to set things up before the call, rather than
> applications. I'd have thought the reverse would be true.

I am scratching my head here trying to figure out what you are talking about.
For block devices you either have a statically allocated array or kalloc
some space, copy the data from user land into kernel space and update a
pointer or two. After it is in the kernel land array you are free to
mangle the data at your hearts content.

> In addition, its also not always possible to know whether the parport routine
> that is being called is verifying a buffer. It may not if its dealing with
> single bytes of data, as opposed to a larger buffer.

Umm... I can not seem to locate a get_user() in my 2.2.0 source code here
as part of the parport drivers. I think you will find that the code that
dirrectly interfaces with user land is responsible for buffer management.
(here I user the term buffer managemnet loosely in the context of
shifting data between the application and kernel regions).
 
> This is particularly relevant in the vc-qcam driver I'm writing which makes a
> huge number of calls to parport.

The bulk of the parport calls should resolve down to single "asm" statements,
at least for the port access level.

> Any comments or efficient workarounds? Having to wrap set_fs() around every
> call to a parport api seems ridiculous.

As I said before, try bulk copy between userland and kernel using
(reach here for grep on the kernel headers) with the

#include <asm/uaccess.h>
copy_to_user(to,from,size)
copy_from_user(to,from,size)

I hope this gives you some ideas....

David Campbell

-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --



This archive was generated by hypermail 2.0b3 on Sun 28 Mar 1999 - 17:02:24 EST