Re: [Dri-devel] Pseudo DMA?

[Frank C. E. <fe...@ai...>]

On Sunday 10 February 2002 04:31 am, Gareth Hughes wrote:
> I don't think you should count on being able to reset the chip once
> you "detect" a lockup.  Things like bus lockups are pretty fatal
> events.  Besides, I've yet to see the sample code for resetting
> the ATI chips actually work reliably, if at all :-)

The sample code was missing a piece that we stumbled across.  They mention 
resetting the engine by setting the interrupt on the BUS_CNTL register but 
then tell you nothing about it.  I don't know about bus lockups but the DMA 
could be reset after it was messed up by doing the extra step.

> W.r.t. your first comment, think long and hard about what you could
> do with a user-space programmable DMA engine that can read and write
> arbitrary locations in system memory.  It may be hard, but it's entirely
> within the real of possibility that you can become root.

The command pathway doesn't seem to allow for that.  Only the blit pathway.  
I've coded only inbound to the aperture writes with that pathway, but not 
outbound (there's very little that anything other than the X server needs to 
do that sort of thing).

> Similarly, you should not design a mechanism that allows the chip to
> lock up for any other reason than a bug in the driver.  There is
> nothing but "proper" security -- it's either a secure driver, or it's
> not.  It is unacceptable to have a non-alpha quality driver that has
> backdoors like this.

Ok, that's going to make the machine do the work twice- once for filling the 
buffer with verticies and then again to unpack them and submit commands to 
the engine.  I was trying to avoid a bottleneck- but, okay, if that's not 
acceptable, I'll do it the other way.

> Please think about what you're suggesting.  These chips can read
> and write arbitrary locations in system memory.  For all chips that
> have this feature, the only safe way to program them is from within
> a DRM kernel module.  Only clients that have been authenticated via
> the usual (X auth) means are able to talk to such modules.  There is
> simply no other way to do it.  You can trust the X server and the
> kernel module.  You CANNOT trust anything else -- a client-side 3D
> driver, something masquerading as one, whatever...

The engine doesn't seem to allow for that if you disallow the user to set up 
blit operations.  I'd have to run a test to be sure, but I think the engine 
would lock up if you messed with the setup registers and tried to transform 
the gui-master into a blit and that'd be only way what you suggest could 
happen with the RagePRO from what I can tell.

> There is a reason why all the DRI drivers for commodity cards are
> designed like this.  It's a pain, but that's the price you pay for
> a secure system.

The other cards seem to mainly have nice pathways for submitting verticies, 
etc.  This one doesn't.  I'll recode it to accomodate no commands but pure 
data- it's not just a pain, it's horribly inefficient with this card the way 
it's designed.  

-- 
Frank Earl