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. > 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. 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...) -- Frank Earl _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
