On 2002.05.25 06:10 Leif Delgass wrote: > On Fri, 24 May 2002, Frank C. Earl wrote: > > > On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote: > > > > > I've committed code to read BM_GUI_TABLE to reclaim processed buffers > and > > > disabled frame and buffer aging with the pattern registers. I've > disabled > > > saving/restoring the pattern registers in the DDX and moved the wait > for > > > idle to the XAA Sync. This fixes the slowdown on mouse moves. I > also > > > fixed a bug in getting the ring head. One bug that remains is that > when > > > starting tuxracer or quake (and possibly other apps) from a fresh > restart > > > of X, there is a problem where old bits of the back- or frame-buffer > show > > > through. With tuxracer (windowed), if I move the window, the problem > goes > > > away. It seems that some initial state is not being set correctly or > > > clears aren't working. If I run glxgears (or even tunnel, which uses > > > textures) first, after starting X and before starting another app, > the > > > problem isn't there. If someone has a cvs build or binary from > before > > > Monday the 20th but after Saturday the 18th, could you test to see if > this > > > happens? I'm not sure if this is new behavior or not. > > > > > > I tried removing the flush on swaps in my tree and things seem to > still > > > work fine (the bug mentioned above is still there, however). We may > need > > > to think of an alternate way to do frame aging and throttling, > without > > > using a pattern register. > > > > I've been pondering the code you've done (not the latest commited, but > what > > was described to me a couple of weeks back...) how do you account for > > securing the BM_GUI_TABLE check and the pattern register aging in light > of > > the engine being able to write to most all registers? It occured to me > that > > there's a potential security risk (allowing malicious clients to > possibly > > confuse/hang the engine) with the design described to me back a little > while > > ago. > > Well, I just went back and looked at Jose's test for writing > BM_GUI_TABLE_CMD from within a buffer and realized that it had a bug. > The register addresses weren't converted to MM offsets. So I fixed that
Indeed. The other registers were being specified by their value and not their macro, so I forgot about that detail... > and ran the test. With two descriptors, writing BM_GUI_TABLE_CMD does > not > cause the second descriptor to be read from the new address, but > BM_GUI_TABLE reads back with the new address written in the first buffer > at the end of the test. Then I tried setting up three descriptors, and > lo > and behold, after processing the first two descriptors, the engine > switches to the new table address written in the first buffer! I think > it's because of the pre-incrementing (prefetching?) of BM_GUI_TABLE that > there's a delay of one descriptor, but it IS possible to derail a bus > master in progress and set it processing from a different table in > mid-stream. Plus, if the address is bogus or the table is > misconstructed, > this will cause an engine lockup and take out DMA until the machine is > cold restarted. The code for the test I used is attached. > Wow! Bummer... I already had convinced myself that the card was secure! > So it would appear that allowing clients to add register commands to a > buffer without verifying them is _not_ secure. This is going to make > things harder, especially for vertex buffers. This is going to require > copying buffers and adding commands or unmapping and verifying > client-submitted buffers in the DRM. I'd like to continue on the path > we're on until we can get DMA running smoothly and then we'll have to > come back and fix this problem. Yep. It's not the end of the world, but it's gonna mean that the CPU will be a little more stressed, and that we have much more code to do... Good catch, Leif! Jos� Fonseca _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
