From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Fri, 6 Aug 1999 01:31:59 +0200

Re: Matrox GGI accellerator

> > working on the design for /dev/gfx to deal with such issues. I'm modeling
> > /dev/gfx after the way it works on SGI workstations. RIght now if I where

> SGI hardware is probably the strongest hw design. So you may have the possibility
> to cleanly separate access control from 'functional' accesses - that is to
> say that you can feasibly define a /dev/gfx interface. But with other
> types of hardware it may be difficult.

Yes. SGI HW often even supports multiple hardware context states (much like
the task switch registers of a x86 with x>3). That really helps with
multirendering ... :-)

> To do that you really need very fine grain control. Is it really possible to
> mmap any portion of a SGI card framebuffer (at 1 pixel resolution) ? 

No. The resolution is fixed: 0 pixels. No mmap access.

> Don't you have things like 'page granularity' etc. that would hinder 
> the idea?

Yes. Though as a compromise for the broken PC card designs, and as the only
problem is a hosed display, which you can get "legally" by just opening a
big window, topping it and drawing wildly, I think it might be a viable
compromise to try to mmap only the needed stripe. 

Won't stop malicious programs (but as said they can do the same anyway), but
will aid debugging the occasional bound error that happens.

> Note that this idea adresses confidentiality of the fb in fact, no?

This is of no concern under x. If the client has permission to connect to
the X server (it has, it opened a window), it can as well do xwd -root.

> Do you really think that window granularity is necessary ? 

It is nice to have, but you need HW support.

> Again this requires very fine grain control over hardware access. Is
> it really feasible to provide such fine access control (at the bit level
> sometimes) without requiring implicitly a kernel mediation on each
> access to a register ? If it's possible, this approach is IMHO
> pretty good.

It is possible for IO access on a per address basis, but slower than 
just asking the kernel to do the job for you. 

For MMIO it is IMHO not worth the bother. You only have page granularity,
and you should either map a page, if it is entirely safe or access it via
the kernel driver.

> IF the 'safe' accelerations registers are well isolated, say
> between 0x800 and 0x8ff (offsets in the MMIO aperture) then
> we can allow direct access from userspace in that area. 

No. As we have to allow 0x0000-0x1000 for x86 e.g.

Some manufacturers have grasped that fact, but very few ...

> However, of course, if better hardware allows a clean
> policy to be defined and implemented, it may be the
> right way to do - but for that hardware, not for all
> hardware.

Yep.

> compromising safety - but frankly, even with SGI
> hardware I would be surprised that security will
> really be guaranteed [think malicious! ;-)]. 

Probably. Though if the bugs are hidden well enough, chances are low :-).

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =