On Tue, 2005-08-23 at 20:08 +0200, Stephane Marchesin wrote: > 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).
Sure, that's the wrong way to go about it. The rendering primitives should be associated with memory objects in the first place. > > 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... Not with redirected windows, which will all be distinct objects. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
