On Thu, 17 Mar 2005 23:57:57 +0100, Attila Kinali <[EMAIL PROTECTED]> wrote: > On Thu, 17 Mar 2005 17:01:50 -0500 > Timothy Miller <[EMAIL PROTECTED]> wrote: > > > On Thu, 17 Mar 2005 22:27:23 +0100, Attila Kinali <[EMAIL PROTECTED]> wrote: > > > This is IMHO a no-issue. No unprivileged user space programm > > > should be able to insert anything directly into the graphic card w/o > > > the interception of a driver. Any priviledge checking and enforcing > > > has to be done in software as 1) it is impossible to forsee > > > how future OS will handle priviledges and 2) to keep the transistor > > > count down. > > > > The plan is to allow unpriveleged processes to do any evil thing they > > want, as long as it can't compromize system stability. > > Interesting. But may i ask whether it is worth the > transistors spend on this ? It's far more easy to do > that in software in the driver instead of hardware (IMHO).
It's not a transistor thing. It's an ioctl-interface-overhead thing. We're going to have a DMA interface anyhow, and we're going to have a BAR for the engine. The security is in not mapping the engine at all and only selectively mapping graphics memory. There once was a feature in the spec that would allow the GPU to fetch texels directly from host memory. That feature was eliminated both to reduce transistor count and to increase security. > > > With some > > clever use of mmap, we can restrict which pages of the graphics memory > > are visible to a process, but we're unlikely to be able to prevent the > > process from reading or clobbering someone else's windows. The key is > > that the process cannot lock up the engine or initiate arbitrary DMA, > > so there's no security/stability compromize. > > An application clobbering or reading my windows is already a security > risk to me. Just think about an application showing sensitive > data on the monitor and an other user reading the displayed data. > Not a very nice prospect. If it isn't possible to shield > applications against each other, then i would leave this > feature as it might (and most likely will) turn into a bug. Yeah, but it's a bug that every other commodity GPU out there shares, and we're trying to work in even tighter constraints than they have. With the alternatives, the GPU is mapped into your unpriveleged address space, and if you can locate the address space of the engine, you can do all sorts of evil things like DMA kernel memory into graphics memory and back into your process, lock up the GPU, etc. We're not trying to be SGI here, and there are going to be compromises. Remember this: Security is a BONUS with this design. Mostly, this GPU is directed at embedded systems and single-user desktops and workstations. If we are able to prevent your system from hanging or crashing under the worst conditions, consider yourself much further along than you were before. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
