On Saturday 19 March 2005 11:05, Attila Kinali wrote: > On Fri, 18 Mar 2005 14:39:04 -0500 > > Daniel Phillips <[EMAIL PROTECTED]> wrote: > > On Friday 18 March 2005 05:16, Attila Kinali wrote: > > > On Thu, 17 Mar 2005 21:53:04 -0500 > > > > - 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. > > Hmm? Looks like i missunderstand the term PIO. Can you clarify > it for me please ?
Someone correct me if I'm wrong, but I think it goes like this at least on x86: PIO: A program writes to registers (think VGA card, which has registers for the palette for example) by using the outb or outw instruction (this is a privileged instruction on x86, so only the kernel is allowed to do it). This results in the values being written to the appropriate port across the bus (that would be a PCI write burst?) by the CPU. Typically, the card then stores the data in the appropriate register. These registers are on the card, just like the registers in the CPU (EAX, EBX, etc.) are part of the CPU itself. Note how this keeps the CPU busy. That's not good, so DMA was invented. DMA: The card initiates a DMA transfer, since it got a command to do so from the ring buffer. The DMAC (DMA Controller) gives it the go-ahead, and the card reads the data (drawing commands) directly from main memory and stores them in its drawing FIFO, which is just a queue with drawing commands, perhaps in a block RAM. It then proceeds to execute the commands, and the first one tells it to load a texture to a certain address in VRAM. So the card initiates another DMA transfer, reads the data from main memory, and writes it to its on-card VRAM. While all this is going on, the CPU is going on its merry way, perhaps doing T&L calculations for the next frame, or telling the user how happy it is that it doesn't have to worry about shoveling bits and can instead do something smart. So how does this affect security? Well, let's see what an ordinary 3D task can do. It can create a list of commands, and it has an ioctl that effectively allows it to say submit_drawing_commands(&buffer, length); to the kernel. The kernel will then put an appropriate DMA request into the ring buffer, and the card will transfer the drawing commands to the drawing FIFO. The logic that gets commands from that FIFO only understands drawing commands, so there is simply no way for the program to get a malicious command to the logic that would actually execute it. And it can't write to the card's registers via PIO, because that required using a privileged instruction, which only the kernel can do. Now, you can also do completely without PIO by putting the register writes as commands into the ring buffer (i.e., in between the DMA read-my-drawing-commands-please commands), so that the card will fetch them by itself when it has time for them. This is better, because the PCI write burst you cause by doing a PIO register write will interrupt any DMA transfer currently going on (or maybe it will wait, tying up the CPU, I don't know). It has the disadvantage of having a higher latency, which may be a problem for the cursor coordinates for example. It doesn't affect security, because the client can't access the ring buffer directly, and the submit_drawing_commands ioctl the client does have will only add DMA commands in the ring buffer. Does that make sense? Lourens _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
