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/