On Saturday 19 March 2005 00:07, Daniel Phillips wrote: > On Friday 18 March 2005 14:29, I wrote: > > As Timothy pointed out and I should have known, currently there is no > > window-level security for X programs. So we just mmap video memory, > > provide a way of flushing the render pipeline, and we're done. > > > > We should however, keep the window security question alive as a > > background project. To me, it looks like a bleeding wound in X. Doing > > something about it would be a worthwhile long term project. > > OK, I talked this over with some folks here and we noticed that there is a > much easier problem to tackle with a more clearcut benefit. Right now, a > single buggy or malicious unprivileged 3D program can lock up your whole > desktop if it fails to release the hardware lock, and there is not a lot > you can do about it other than restarting X. This we can fix, by moving > the synchronization into the kernel as I described earlier, and I think we > can even do it within the current DRI framework. We can fix this because > of our complete reliance on the indirect DMA command interface for hardware > access. So I think we ought to plan on this right from the beginning.
First of all, this is not entirely correct: You can kill the offending application (if you're able to find out which it is), this will also release the lock. Second, when I first got involved in R300-related experimentation, I wrote a DRM watchdog timer patch that basically killed any (non-root) process that kept the hardware lock for too long (where "too long" is defined as some constant wallclock time). This still has some problems, but it is a lot simpler than what I think you're suggesting (perhaps you might want to clarify). Third, I don't think we rely on indirect DMA completely, and even if we did, it wouldn't have a significant effect on the nature of this and related problems. Having said that, I am definitely interested in looking at those DRM-related problems, but *after* we have a working driver. cu, Nicolai
pgpSHVg91lRDf.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
