On Thu, 17 Mar 2005 22:27:23 +0100, Attila Kinali <[EMAIL PROTECTED]> wrote: > On Wed, 16 Mar 2005 16:11:52 +0800 > [EMAIL PROTECTED] wrote: > > > Proposal: > > Why don't you include a security register alongside the DMA registers. When > > the > > commands are DMAed in and proccessed any "priviliged" command encountered > > would > > either be turned into a no op or halt execution if the security register is > > set. > > 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. 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. > > > Ideally an interrupt would be generated in both cases to let the > > user/programmer know. > > Way to slow. An interrupt on every command (worst case if all > commands are priviledged) will nearly lock up the machine. > Beside, user space programs cannot register interrupt handlers. Most interrupts have to do with engine idle and ready-for-data, which are only of interest to the kernel or X11 server anyhow. Since an unpriveleged process would not have direct access to the engine registers, this isn't a problem. > > I don't know how this scheme maps to the kernel DRI > > security mechanisms. I haven't looked into the kernel source code for this. > > Im > > finding it a lot easier to understand the Xorg XAA code/design then the > > kernel > > header files. > > Interesting, i find it the other way round :) > > > I don't know what it does to the FPGA/transistor budget. > > Horrible. > > > > PS. I hope the card will support native 3.3 V PCI. My SGI 320 refuses to > > boot if > > some so called "univseral" cards are placed in the slots. > > Unlikely. But that's IMHO a SGI hardware bug, so let them fix it. I think we've had to deal with this before. It involves multiple power regulators. I think we had this issue with a PA/RISC box. We'll see. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
