On Thursday 14 February 2002 10:33 am, Keith Whitwell wrote: > I haven't had a good look at security on either of these cards, but it's > definitely worth doing, both to find out if we're doing too little and if > we're doing too much.
I've been looking at the i810 programmer's guide trying to understand why it's acceptable to send commands mixed with the verticies to it (since that is the same boat we're in with the RagePRO), and we might be doing too much in one aspect, and not enough in others. Someone should look over my shoulder here and see if I'm plain flat missing something... While we keep someone from altering the buffer while it's being operated upon by the engine (unmapping the buffer), there is nothing keeping someone from submitting bogus commands to the instruction parser on the chip directly from the user side of things. However, there's the something of the equivalent of user versus kernel space operation with this chip (and we are using it) that keeps the outside world from using it to DMA things, etc. that they're not supposed to so long as you deny them access to the ring buffer. We are doing that, but unfortunately, the driver doesn't seem to use the interrupt framework built into the chip to reset itself after an error has occured (we're using it only to handle DMA flushes in the driver according to comments in the code and my reading of the code in question)- which it has to do to continue operation after a protection violation, according to the programmer's guides. The mapping/unmapping doesn't seem to buy us much in the way of protection and is slow. According to the documentation from Intel, the chip is designed to handle these situations for us. While I know the chip is slow, is it really needed to do this operation which is a very big bottleneck on performance? -- Frank Earl _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel