On Sun, 02 Dec 2007 20:59:16 +0000, José Fonseca wrote: > On Fri, 23 Nov 2007 00:27:37 +0100, Pascal Vincent wrote: > >> Hello, >> >> can you please indicate the current ATI mach64 DRI status. In fact, >> http://dri.freedesktop.org/wiki/ATIMach64 page is not so clear so i >> don't have the clear responses to - is mach64 is now secure ? this >> means : >> - is it now included in DRI and Mesa ? (the response seems to be >> yes) - is mach64 module is now included in kernel ? (it seems not) >> and if not why ? >> >> >> Tks a lot for clarification >> >> Pascal > > Pascal, I wrote that wiki page several years ago. I never got around to > do it, because it involved a non trivial amount of work, and I > approached in a naive way (trying to do too many things at the same > time, instead of doing gradual changes). > > I need to reevaluate those statements, especially, concerning the > security, and the best way to do it. > > The mach64 driver has three parts: one in Xorg, another in Mesa, another > in the kernel. The unsafe part is the kernel part. And that's probably > why is not included in the stock kernel. > > The reason the mach64 kernel module is unsafe is because it allows an > OpenGL application to send malicious commands interspersed with the > vertex data. Those malicious commands could give control over the > physical memory, and therefore be used to obtain root privileges in > theory. > > The mach64 kernel needs to be changed to verify and copy the data to > private memory. Or at least unmap the memory from the client before > verifying it and handing to the hardware. > > Or so I though... I need to verify how much control over the physical > memory the client can actually get. As I'm unsure if it is just the > memory in the AGP aperture, or the whole memory. If it is just the AGP > memory, then there is no risk. > > José
The work to get Mach64 secure was already done by George ( https://bugs.freedesktop.org/show_bug.cgi?id=6242 ). Dave Airlie had concerns with the blits, but I reviewed the code with him I found it to be secure (basically we don't let the client touch dma buffers -- it's not the most efficient way for blits, but is is simple as it doesn't imply maintaining two sets of buffers, one private another public). Now I've cleaned up the code a bit (especially eliminating some macros) and commented more, to make it easier to understand and maintain. Hopefully it will be merged soon. José ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
