On Friday 03 May 2002 09:49 am, you wrote: > As I was studying the specs and code to be able to understand and reply to > Leif's previous post (which I haven't completed yet..), I noticed at the > same time a bug and a feature which could mean that blind client buffering > could be insecure after all.
After testing, it doesn't appear to be. > Only commands which are on block 0 of MMIO region can be streamed into a > GUI master operation, as said in the BM_DATA register spec (8-11). The > MACH64_BM_GUI_TABLE_CMD is an alias in this block exactly for this > purpose, i.e., to be streamed trhough the GUI command FIFO, as said in its > spec (8-12). Doesn't this means that we can initiate further GUI master > operations from a command buffer since, once the first GUI master > operation is setup, it's only necessary to set MACH64_BM_GUI_TABLE_CMD and > MACH64_DST_HEIGHT_WIDTH to fire it up - both accessible from GUI FIFO. Since, upon examination, many of the pieces of documentation we have gotten for the display chips are either incomplete, testing a theory is the best way of knowing whether or not something will do what you expect. I thought that it might be that way, so I tested to see if I could I could re-submit new GUI-master operations to the engine. It appears from the tests that I ran that the GUI-master operation only works with GUI setup and GUI comand registers. Setting up a new GUI-master or BLIT operation did nothing and seemed to just leave the registers set with those values (this was for one descriptor entry's worth of data- we may need to set up a test with MUCH larger spaces with the code in place to be certain...) no actions were carried out (probably because they're not FIFOed and the engine WAS busy...). > Although firing up a stream of arbitrary commands shouldn't be a reason > for concern since the commands are only innocent(?) GUI operations, this > gives the ability of setting up any descriptor table. One consequence is > that if this table is invalid the whole DMA engine is unnoperational until > a cold reset. Another is that they can access to any register... Yes, and they can set it to any value, but the engine doesn't seem to act on any command settings done this way. It is one of the reasons why I said we ought to push a few register reset operations on some of the critical registers (BUS_CNTL, for example) so that if something DOES initiate a command immedately afterward that expects the settings that were there prior to a DMA pass they won't be broken. You can set up a new descriptor table, but there is no direct way to fire it off after the pass is over with and you can't do it in the middle of a pass (Because your GUI commands needed to fire off a pass are NOT put in the FIFO, they're executed directly from the bus-mastering engine...)- so, if you reset the bus-master control registers at the end of a pass, there will be nothing a malicious client could do to initiate their own passes, bogus or otherwise. > I plan to build a test case for this, but I would like to hear preliminary > opinions about this, in case I'm missing something. Frank, have you tested > this before? Yes, pretty extensively, but I didn't have time to set up tests for spanning multiple pages- we ought to do that one last one before commiting to the path we're now looking at. -- Frank Earl _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
