On Sunday 10 February 2002 05:08 pm, Gareth Hughes wrote: > How do you prevent a client-side "driver" from sending down blit > commands, without inspecting the DMA buffer?
The operations are two distinct beasts with similar interfaces. You can send register/value pairs or tell the engine to blit from system memory to the aperture or from the aperture to the system memory. If the engine is busy handling a gui mastering opertion or a blit operation, I don't think it takes kindly to you yanking it from one mode to another (which would be the only way you could do that...)- I think it'd hang on you. I'd have to try it and see for sure. If it does let you set up and run another DMA pass, then there's a problem- otherwise it's like I said, if you don't allow them to down blit they can't do it. > You can't allow the user-space portion of the driver to fill in > the register programming words in the DMA buffer. Vertex data, > sure, that's okay. The registers are mapped into two separate > pages for PIO access, but all that goes away when you're doing > DMA transfers... The problem is, this chip doesn't accept just verticies like the G400. It wants commands. I'm trying to understand the i810 code since it seems to be the closest situation to my own. It doesn't look like there's a lot of copying there for vertex submissions but yet according to Keith's email earlier today it's got commands in the vertex stream just like this situation. How are they different? (Note that this is not me trying to fob off half-baked stuff here; I'm trying to reconcile the desire for optimal performance with more than a bare semblence of security. That, combined with coming to a complete understanding of what will/won't be acceptable so that the next driver I work on won't take as much time because of learning curve...) I'd like to know why so that it'll all kind-of click. At the time I proposed it, if every one of my assumptions are valid, I would have thought that a defensive mode for the code that does manage a slight chance to crash things would have been a good idea. > Exactly how do you do this? You'd have to set up the buffer with a set of register/value commands that set up a new DMA pass or changed the current one from gui-mastering to blit. Once you'd set that up, you'd have to have to have a descriptor entry that you've munged to point to your code space that blitted from a system area to your area, going through the frame buffer. Or, you'd have to have a bogus descriptor table that performed the same task. In the case of the first possible exploit, that would be nigh-impossible. I do not allow them control or access to the descriptor table for blits or DMA commands- they'd have to have access to the internals of the DRM module (which implies they have more than enough to mess things up anyhow) to use that route. The second route requires memory mapping ability (i.e. John Carmack's memory hack in the RagePRO Utah-GLX driver or the scheme we're using in XFree86 and the DRM) along with the ability to get a 16k aligned page (aligned in bus address space...) and the bus addresses for each and every part of the data space you're using- this would require access at root user levels as well. I could be missing something- that's why I'm discussing it now instead of doing it in a submitted branch and then arguing over it. :-) > It's a damned slow chip. With anything over about a 4-500MHz > processer, you'll still be able to saturate the chip -- we got > it to hit the hardware limit doing PIO with a 600MHz PIII, I > seem to recall... Like I've been saying, I was trying to wring out the last drops of performance out of the card without doing too much of a compromise of things to do it. I guessed wrong on how far I could go- I didn't know, now I do. (Though I partly question the maxing out part- yes, it's a slow chip, but I've not seeing what you're claiming on my end. I've got a PII-450 and it's peak with Utah-GLX was ~250 fps with gears and something like a low 20-ish fps with Q3A. I'm only seeing ~110 fps with the same machine and the PIO hack version of the Mesa driver in the branch. Is a PIII-600 really nearly 2 times faster a machine than the PII-450? :-) And, just because it's a slow chip doesn't mean I should do something else to slow things down further without being absolutely needed. -- Frank Earl _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
