On Wednesday 16 March 2005 07:54, Nicolai Haehnle wrote: > On Wednesday 16 March 2005 12:08, Daniel Phillips wrote: > > On Tuesday 15 March 2005 18:43, Nicolai Haehnle wrote: > > > If we enforce window boundaries (which is btw not enforced by any > > > graphics driver on Linux that I know of), we would also have to > > > think about how mmap()'ing the framebuffer could (or couldn't) > > > work. > > > > Can you do that? If a normal task can do that, then forget about > > per-window security, it's impossible. But I have a feeling it's > > not allowed. > > Well, software rendering fallbacks need some way to read to and write > from the framebuffer. All current DRI drivers do this via a mapping > of the framebuffer.
But that is a privileged task. It is not a security worry as long as it's not full of bugs. > > > The current DRMs actually seem dumb. The DRM only enters commands > > > into the ring buffer as a response to ioctls from userspace, and > > > if the buffer is full, it will busy-wait for space to become > > > available. I haven't checked all drivers out there, but all that > > > I've looked at so far work like this. > > > > I feel it's worth taking a run at doing that better. The worst we > > can do is fail and have to fall back to sucking as much as > > everybody else. > > I agree. Fortunately, this shouldn't affect hardware design too much. > I believe an IRQ that is emitted when the ringbuffer read pointer > passes a certain mark should be enough. For the DRM part it is enough. What I am worried about is how the interface to tasks drawing by indirect DMA is going to work. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
