[lkml]   [1999]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject3Dfx 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

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.031 / U:0.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site