Re: [patch] My AMD IDE driver, v2.7

Jeff Garzik
2002-03-12T01:34:25Z

Erik Andersen wrote:

>On Mon Mar 11, 2002 at 07:34:26PM -0500, Jeff Garzik wrote:
>
>>Reason 1: Standard kernel convention. In other ioctls, we check basic
>>arguments and return EINVAL when they are wrong, even for privieleged
>>ioctls.
>>
>
>I have no argument with basic command validation. But take a
>look at ide_cmd_type_parser(), for example. Do we really need a
>giant switch statement listing all the allowed commands, just so
>we can throw back a IDE_DRIVE_TASK_INVALID to user-space if they
>decide to send down some undocumeted firmware wiping commands?
>Especially since that giant struct of allowed commands is
>duplicated in ide_pre_handler_parser() and ide_handler_parser()
>
I agree the implementation could be improved.

Your first question is really philosophical. I think that people should
-not- be able to send undocumented commands through the interface...
and in this area IMO it pays to be paranoid.

If we wanted to be ultra-super-paranoid, drop the ioctl and taskfile
parser, and implement the taskfile checks via SMM mode callbacks from
activity on the IDE ports ;-) That way we know the NSA is not doing
something sneaky, as well as supporting unlimited SMP bit-banging from
userland. Can you say ug and non-portable even to a lot of ia32
platforms. :)

So, the implementation may need improvement, but we do (a) want the
taskfile ioctl [and one for scsi too], and (b) want to implement some
amount of mininal sanity checks on the requests.

Jeff