On Monday 01 November 2004 07:01, Thomas Hellström wrote: > You are probably right, and it would be quite easy to implement such > checks in the via command verifier as long as each lock is associated with > a certain hardware address range. > > However, I don't quite see the point in plugging such a security hole when > there are a similar ways to accomplish DOS, hardware crashes and even > complete lockups using DRI. > > On via, for example, writing random data to the framebuffer, writing > random data to the sarea, taking the hardware lock and sleeping for an > indefinite amount of time. Writing certain data sequences to the HQV locks > the north bridge etc. > > Seems like DRI allow authorized clients to do these things by design? From what I've learned, the DRI isn't exactly designed for robustness. Still, an authorized client should never be able to cause a hardware crash/lockup, and an authorized client must not be able to issue arbitrary DMA requests. As far as I know, all DRMs that are enabled by default enforce at least the latter.
Personally I believe that in the long term, the DRI should have (at least) the following security properties: 1. Protect against arbitrary DMA (arbitrary DMA trivially allows circumvention of process boundaries) This can be done via command-stream checks. 2. Prevent hardware lockup or provide a robust recovery mechanism (protection of multi-user systems, as well as data protection) Should be relatively cheap via command-stream checks on most hardware (unless there are crazy hardware problems with command ordering like there seem to be on some Radeons). I believe that in the long term, recovery should be in the kernel rather than the X server. 3. Make sure that no client can cause another client to crash (malfunctioning clients shouldn't cause data loss in other applications) In other words, make sure that a DRI client can continue even if the shared memory areas are overwritten with entirely random values. That does seem like a daunting task. 4. Make sure that no client can block access to the hardware forever (don't force the user to reboot) I have posted a watchdog patch that protects against the "take lock, sleep forever" problem a long time ago. The patch has recently been updated by Dieter Nützel (search for updated drm.watchdog.3). However, I have to admit that the patch doesn't feel quite right to me. 5. Enable the user to kill/suspend resource hogs Even if we protect against lock abuse, a client could still use excessive amounts of texture memory (thus causing lots of swap) or emit rendering calls that take extremely long to execute. That kills latency and makes the system virtually unusable. Perhaps the process that authorizes DRI clients should be able to revoke or suspend that authorization. A suspend would essentially mean that drmGetLock waits until the suspend is lifted. I know that actually implementing these things in such a way that they Just Work is not a pleasant task. I just felt like sharing a brain dump. cu, Nicolai
pgpkLU7ArzKbS.pgp
Description: PGP signature
