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

Reply via email to