Re: [Linux-fbdev-devel] fbdev API problems

[Sven <lu...@dp...>]

On Thu, Nov 22, 2001 at 02:40:00AM -0800, Matt Sottek wrote:
> On Thu, 2001-11-22 at 00:37, Sven wrote:
> > On Thu, Nov 22, 2001 at 12:34:03AM -0800, Matt Sottek wrote:
> > > >The framebuffer itself is pretty safe to export to userland.
> > > 
> > > I assume you mean to allow people to mmap the framebuffer? Yes this can
> > > usually be safe, but only the screen data. Most chips use graphics
> > > memory of some type for dma command buffers. Most chips cannot safely
> > > give you full access to such memory areas. The sysmem_start and
> > > sysmem_length seem to cover the whole graphics region, not just the
> > > visible framebuffer. This is likely not safe.
> > 
> > DMA is not useable outside of the DRI anyway for now, or do you know of any
> > userland app doing this ?
> > 
> > I guess you need to have root access to the fbdev or something such to be able
> > to do dma, not sure though.
> 
> Yes only the DRI is doing dma. It doesn't matter who is doing it.
> 
> What I was pointing out is that you cannot just let users map the
> "framebuffer" memory (meaning all of the graphics memory) because some
> of that memory may contain active dma command buffers which could be
> hijacked to do insecure things. Like, for instance, blit
> something from system memory into the framebuffer such that you
> can then read it, or write to random areas of memory.

And you can open the fbdev once X has locked it and do mma stuff ?

> > Anyway, even X is not able to do DMA outside of the DRI setup. I would have
> > liked it when writing Xv support for the permedia3 chip.
> > 
> So write a DRM :)

mmm, ...

I was in the process of doing this, mainly for DRI and OpenGL purpose, it
partly exists already anyway, but then RL asserted itself again, and i don't
have the time anymore :((((

Maybe later on ...

Friendly,

Sven Luther
> 
> -Matt
> 
>