Messages in this thread | | | Date | Fri, 12 Mar 1999 09:36:07 -0800 | From | Daryll Strauss <> | Subject | 3Dfx security issues |
| |
Yes, the device driver for the 3Dfx hardware makes it easily possible to crash the machine. As you noticed, there are a couple of big problems. First, is that it mucks in PCI space. Second, if you send random cruft to the MMIO space you can crash the board. This is why I have made no effort to put this into standard kernels.
So, why did I create it and is it any better than setuid? I figured it was better than setuid, because the applications getting linked against Mesa had no security built into them. Quake would read arbitrary files, and it was running setuid to speak to the 3Dfx hardware. So, this limited the problem to bad programs crashing the machine as opposed to reading and writing arbitrary files.
Second, the crash problem seems to difficult to work around. For example, the original Voodoo Graphics required that you "SNAP" vertices. That means subpixel values had to be a multiple of 1/16. If you passed unsnapped vertices to the Voodoo Graphics you hung your hardware. Glide didn't check for snapping because the performance hit was too large. Having /dev/3dfx check for valid data would require all of Glide to be in the device. This would cause a big performance drop, would bloat the kernel, and can't be done for intellectual property reasons.
It seems that any of the kernel graphics driver projects are moving to similar approachs and will have similar problems. The question is how can this be handled better within the existing contraints?
- |Daryll
- 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/
| |