> > It didnt - its a security hazard. Any user with access to it can crash
> > the entire machine
>
> I am probably missing something, but access to both /dev/3dfx and (e.g.)
> /dev/mem is controlled by filesystem permission rules. Writing garbage to
> either will crash the entire machine. Why is one a security hazard and
> another is not?
The 3dfx can lock the pci bus if fed garbage. The /dev/3dfx driver
doesn't stop garbage being fed in, and so has no benefit over suid
glide libs which tickle the hardware directly.
Imagine if writing a bad byte sequence to /dev/dsp caused your hdd
to corrupt itself. This is basically the same thing. It's not what
you expect from a /dev interface, so it gets the thumbs down.
> I think having 3dfx in the official kernel is a good idea - think about
> it, if you have a 3dfx card you *will* install 3dfx module, be it
> hazardous or otherwise. If you do not have 3dfx hardware it is silly
> to compile the driver when configuring the kernel, thus all hazards
> avoided automatically.
The proper way is to have an opengl interface which prevents nasty
garbage being sent to the 3dfx card. This has numerous other neato
benefits too, like hardware independence for 3d developers, and an
already well documented API that ties in nicely with X11 if you're
looking for that sort of thing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/