Re: Multiple hardware locks

[Thomas Hellstr�m]

Nicolai Haehnle wrote: 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. Hmm, correct me If I'm wrong, but after a brief check in the code, it seems like the current _DRM_LOCK_IS_HELD() used in  dma buffer submission IOCTLS just checks that the lock is indeed held, but not if it is held by the current caller. Thus any authorized client should be able to sneek in DMA commands while the lock is held by another client or the X server. -> potential system crash. /Thomas