On Saturday 25 May 2002 12:10 am, Leif Delgass wrote: > 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.
Check back to what I'd said for my work- how I'd envisioned things working. It doesn't really rely on a register being set. Yes, it uses a register to verify a completion of a pass, but the main way to do that is to see if the chip's idle- it's more of an extra, redundant check. If the chip is idle, we know it's done with the pass. If it's not idle after about 3-5 interrupts, you know it's probably locked and needs a reset. Now, with the DRI locks, etc. we can ensure that we know there's going to be nobody that isn't a client pushing stuff out until we're done and flagged as such. We also know that nobody's going to be allowed register access, so they can't keep the engine on the chip busy except by DMA requests. DMA requests are not initiated by the the callers, they're handled by a block of code tied to an interrupt handler in the module. This code, if it gets the lock, submits a combined DMA pass of as much of the submitter's data as is reasonable. We then check to see if that pass is completed every time the interrupt gets called. Upon completion, you unlink the buffers in the pass and hand them to the free list. With that, you're already as secure as you're likely going to get with the Mach64- the DRM is in the driver's seat the whole time for any submitted data. Otherwise, you're going to be doing copying of some sort, which pretty much burns up any speed advantages the "optimal" way of doing this gives you. -- Frank Earl _______________________________________________________________ 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
