Quoting Attila Kinali <[EMAIL PROTECTED]>: > 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.
Maybe I have the wrong understanding of the DRI security mechanism. My understanding is that a opengl rendering process will need direct access to hardware to accelerate its operation. Having a memory map to the hardware registers means that in theory it could overwrite the hardware registers with arbitary data if program has a bug or goes out of control. Since the hardware design is DMA based instead of memory mapped based then the to implement security it will either have to 1) Make privilaged commands executed by PIO instead of DMA buffers so do not have to memory mapped into the clients memory space or 2) have a mechanism for trapping privilaged commands when they are processed by the hardware. > > 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. I am thinking that the interrupts would be processed by the kernel driver and logged to the kernel log. The X server could possibly listen for them as well. > > 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. That kills the idea then. > > > 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. It could very well be a SGI hardware bug. Unfortunely SGI doesn't support the VW 320 anymore. The story goes that they ported over the SGI Xserver to Linux x86 and demoed them on the 320 at SIGGRAPH 99. Within a week the project was cancelled and design/development team (and design documents!) was liquidated. The conspiricy theory says something about Microsoft Legal being involved. If SGI released the design documents (if they still have them) then the computers would be very capable Linux workstations and could have improved Mesa/XOrg immensensly when porting them over to their unique design, these old beasts support independent/simultaneous multithreaded OpenGL rendering and OpenGL rendering direct to video. End Rant! Tim. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
