> The log design presents numerous opportunities for rogue processes to do > bad things. At some level, that's inherent in the nature of direct > rendering. If you don't trust the processes, don't enable direct rendering.
Thats a very poor answer to the problem. DRI needs to be moving towards being more secure, and building in assumptions of insecurity just makes it worse when better cards are used. Its critical that the kernel knows what memory on the video space is being used for command queue and protects it. From the description of the SiS turboqueue I suspect you may be able to root a sis video box that way but without full docs I can't tell. Other stuff like textures is merely annoyance value. Knowing who owned a block for cleanup matters and the DRI lock/mem handling on some chips already handles it. Its also cheap because you only have to track some kind of texture handles not pages for cleanup. Alan ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
