On Sat, 19 Mar 2005 12:40:44 +0100, Lourens Veen <[EMAIL PROTECTED]> wrote:
> > 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. You're leaving out memory-mapped I/O. Of course, I/O space and memory-mapped space are basically the same things. "Programmed I/O" means that your program initiates all individual reads and writes to the address space, by using instructions like in, out, move, load, store, etc. The biggest problem with PIO is that the CPU is tied up during the transaction, using not just memory bandwitdth but also CPU time that could be better spent. Also, some architectures, like SPARC, are horribly inefficient at PIO (by design). Not that the device can interpret the transaction any way it wants. For instance, TROZ uses some of the address bits to determine whether the register write is just a register write or if it also includes a rendering command. > > 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. This is right. Also, like a network or sound card, we'll be using DMA not just for commands but to move raw data, like images. > 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. Exactly. > 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. Oh, yeah. I forgot to add that to my list of DMA commands that can go in direct but not indirect: Arbitrary register writes, based on their PIO addresses. > Does that make sense? Hai, gozaimasu. :) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
