Frank C. Earl wrote: > > On Friday 08 February 2002 07:09 pm, José Fonseca wrote: > > > Does this mean that client code can lock the card but is not really > > capable of putting the security of the system in danger? > > Depends on what you define as "in danger". It won't allow a user to commit > local or remote exploits to gain root, etc., but it could be used to lock up > the console such that it requires a remote session of some sort to do a > reboot. This is why, when it passes muster, I'm putting it in a seperate > branch- it's usable, and should be fairly stable, but it's not protected from > malicious clients, etc. To be a "proper" secure driver, it HAS to be > such that you can't DoS the box via the driver if at all possible. Since > there is no specialized groupings of commands (such as one to push a lot of > verticies to the card), I would have to create a shorthand system that the
> module would interpret and then generate the right commands for the DMA > channel to use, or come up with a way to detect a lockup on the chip and do a > proper reset. The first option has an extra inner loop to process against > (It took cycles to FILL the list, now you're taking cycles to unpack and > re-express them in a form that the card can handle...), eating cycles that > could be used elsewhere in the system. The second option presumes one can > detect cleanly a locked up chip always and do a reset always. I don't think you should count on being able to reset the chip once you "detect" a lockup. Things like bus lockups are pretty fatal events. Besides, I've yet to see the sample code for resetting the ATI chips actually work reliably, if at all :-) W.r.t. your first comment, think long and hard about what you could do with a user-space programmable DMA engine that can read and write arbitrary locations in system memory. It may be hard, but it's entirely within the real of possibility that you can become root. Similarly, you should not design a mechanism that allows the chip to lock up for any other reason than a bug in the driver. There is nothing but "proper" security -- it's either a secure driver, or it's not. It is unacceptable to have a non-alpha quality driver that has backdoors like this. > > Sorry for the dumb question (my knowledge of the DMA mechanism is still > > rather incomplete..), but in what way the distinction of the set of > > commands (in the DMA buffers I presume) affects the security? > > Depends on the chip. In the case of the RagePRO, there is literally nothing > keeping you from submitting commands in the DMA stream that can lock up the > chip. Again, nothing stopping you from submitting commands that changes your UID to '0', hence becomming root... Difficult, but not impossible. > Not very many (if any of them...) of the routines in the XAA driver > for the RagePRO expect a hung card (because they're not doing anything that > COULD lock the card) and there's a couple of locked up states from the DMA > pass that leave the engine state as being busy "forever"- and end up being > deadlocked, thus hanging the console but good. If the XAA driver and the > kernel module could check unobtrusively for a locked up state and do a reset > if it is locked up, the situation would go from being an insecure one to a > relatively secure one (As secure as it's going to get and not impair > performance...) Please think about what you're suggesting. These chips can read and write arbitrary locations in system memory. For all chips that have this feature, the only safe way to program them is from within a DRM kernel module. Only clients that have been authenticated via the usual (X auth) means are able to talk to such modules. There is simply no other way to do it. You can trust the X server and the kernel module. You CANNOT trust anything else -- a client-side 3D driver, something masquerading as one, whatever... There is a reason why all the DRI drivers for commodity cards are designed like this. It's a pain, but that's the price you pay for a secure system. -- Gareth _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
