Michel Dänzer wrote:
You'd need the same stuff that you need to protect system memory. You'd
need a hardware MMU that could block the accesses. It might be possible
to do it in software by looking at the command stream, but I suspect
that would be pretty expensive. It would be worth a try, I suppose.
Yeah, I don't expect it to be prohibitive; we're basically doing just
that for Radeons already.
Well, right now any app can use BITBLT_MULTI to read/write to others
video memory, for example. Not that it's a problem to me, or that I wish
to solve it by auditing all the dri drivers to add the necessary checks :)
As for the performance, what is done right now (checking that the offset
falls within a given region) is some orders of magnitude simpler than
what we would have to do (checking the offset against all regions
allocated by a process).
Also, with the current log design for the memory manager, it is possible
for a rogue process to make the log wrap and not call the
force_log_update ioctl, thus being able to create some kind of race
condition where the drm believes it still owns the memory but another
process has allocated it.
Another part would be to only allow mapping owned parts of the
framebuffer.
You'd have to get the cliprects from a trusted source then...
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
