Forgot to cc the list... -- Leif Delgass http://www.retinalburn.net
---------- Forwarded message ---------- Date: Sat, 25 May 2002 12:56:08 -0400 (EDT) From: Leif Delgass <[EMAIL PROTECTED]> To: Frank C. Earl <[EMAIL PROTECTED]> Subject: Re: [Dri-devel] Mach64 dma fixes On Sat, 25 May 2002, Frank C. Earl wrote: > On Saturday 25 May 2002 12:10 am, you 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. What prevents a client from modifying the contents of a buffer after it's been submitted? Sure, you can't send new buffers without the lock, but the client can still write to a buffer that's already been submitted and dispatched without holding the lock. > 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. The registers are already being mapped read only in client space now. > 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. I don't see the interrupt method being that different from a security perspective. The DRM is "in the driver's seat" in either case, the method without interrupts is essentially the same, but with the trigger for starting a new pass in a different place. The problem isn't just relying on reading registers that can be modified by the client, but ensuring that the client doesn't add commands to derail the DMA pass or lock the engine. The only way to make sure this doesn't happen is by copying or unmapping and verifying the buffers. I think the i830 driver does this. Yes, it will impact performance, but I don't see a way to get around it and still make the driver secure. At least this extra work can be done while the card is busy with a DMA operation. -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ 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
