Re: [adaplas@pol.net: Re: Fwd: Re: [Dri-devel] future of DRI?]

[Antonino Daplas <adaplas@pol.net>]

On Mon, 2003-03-03 at 08:27, Alan Cox wrote:

Sven,

Thanks for posting this.  I was actually waiting for the fbdev
maintainers (Geert and James) to respond first.  Seems Geert is
receptive to the idea.

> On Sun, 2003-03-02 at 21:57, Sven Luther wrote:
> > 1. fbdev will be secure.  Without access to the MMIO regions, crashing
> > the chipset is unlikely or at least difficult.  Even malicious blit
> > commands (blits to/from system memory) will not work.  
> 
> For some cases. The truth is a bit more horrible, and current fbdev has
> the same problem here. Any early Athlon, and almost any PII/PIII derived
> chip allows the user to bring the box down if they have access to 
> a mix of cached and uncached RAM.
> 

I do not understand.  Do you mean such as writing to framebuffer memory
and making it execute?

[snip]
> > In linux-2.5, fbcon is already separate from fbdev.  Perhaps in 2.7,
> > fbdev can be further reduced to a minimal core, moving the rest of the
> > code to fbaa.  Exporting the mmio regions to userland must be
> > disallowed. 
> 
> I disagree here. There are chips with useful safe mmio areas for many 
> things. "Exporting mmio regions must be up to the DRM layer"
> 

I was speaking more of fbdev which allows mmapping of the mmio besides
graphics memory.  DirectFB does its acceleration this way. So, yes, this
task can relegated to DRM. 
 
> > Any comments? 
> 
> Take a look at the SiS DRM. It has the memory manager and fb in one
> module but otherwise its not that disimilar to your basic description
> 

Thanks. 

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf