On Friday 18 March 2005 05:16, Attila Kinali wrote: > On Thu, 17 Mar 2005 21:53:04 -0500 > > Daniel Phillips <[EMAIL PROTECTED]> wrote: > > On Thursday 17 March 2005 17:49, Nicolas Boulay wrote: > > > uh ? I beleive that user space lib should talk directly to the card > > > to have the full speed. > > > > Yes. > > Yes and no. Yes, it should be as direct as possible. > No, there needs to be a layer in between that keeps > user space from screwing the card or the whole machine. > > IMHO there needs to be at least a check whether the > send commands can do anything harmfull. I also see > now that Timothy is right, a bit of hw support for this > kind of stuff will help.
What exactly do you propose to check for? > > Furthermore, there may not be anything to split. I propose the > > following: > > > > - An unprivileged task can only submit commands via indirect DMA. > > Each indirect DMA buffer is submitted by ioctling the kernel > > Can you explain this a little bit ? Sure. DRI provides an interface for submitting DMA to a 3D card. It is no doubt intended only for upload/download of card data, however we can use that interface to submit commands as well. This interface is implemented via ioctl. > > - PIO is only available to privileged tasks, normally only the kernel > > driver. > > How is this differentiation going to provide security ? > If i can DMA to any memory location on the card, then i > can also overwrite the PIO registers with indirect DMA. > Or do i miss something ? The PIO registers aren't in card memory, they are on the FPGA. Also, we haven't yet specified how you provide the target DMA address for the card's memory. If we want, we can restrict the possible destination addresses in the card memory. The card itself doesn't have to provide any support for this because the DMA is being submitted via ioctl to our kernel driver anyway, and we can provide security checks there. That said, I doubt anybody will get around to this for a while, nor is it important in order to get something up and running. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
