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 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
