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

["J. Dow" <jdow@earthlink.net>]

From: "Jeff Garzik" <jgarzik@mandrakesoft.com>

> Linus Torvalds wrote:
...
> >One solution may be to have the whole raw cmd thing as a loadable module, 
> >and then I can make sure that it's not even available on the system so 
> >that I have to do some work to find it, and somebody elses program won't 
> >just know what to do.
> >
> >But in that case is should be far removed from the IDE driver - it would 
> >just be a module that inserts a raw request on the request queue, and NOT 
> >inside some subsystem driver that I obviously want to have available all 
> >the time.
> >
> I like this solution, it was the one I was thinking of :)

It leaves me bemused. You speak of a module to install a raw userspace
IO capability. If that module exists the module interface exists. Would
it have to be the module compiled into the kernel that gets run on that
interface? It looks as wide open as ever, to me.

> The entire userspace raw cmd ioctl should be a separate module for 
> precisely the issues you outlined.  If they choose, people can compile 
> that module into the static kernel image, including filter.  Or they can 
> use the module without the filter.  Or they can not use the module at 
> all.  Etc.

Of course, this seems to be one of those compromises between high
availability and high security. It should be made clear that this is
the compromise involved when the raw io filter is compiled in or not.

I'm not sure you can build an unfiltered raw IO capability into the
kernel SCSI, IDE, or anything else and maintain system security.

{^_^}    Joanne