Alan Cox wrote:
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.

Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the trouble with current cards.


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.


Protecting a statically assigned command queue is one thing (something similar to what's currently done on radeon would be sufficient), protecting dynamically allocated video memory is another.

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.

Actually, the long term idea is to have both dri and ddx allocate from the same memory pool. So we can't rely on texture handles for that.

Stephane



-------------------------------------------------------
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

Reply via email to