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

Re: Matrox GGI accellerator

James Simmons <jsimmons@edgeglobal.com> wrote:

> The BIGGEST thing is the need for proper virtualization
> of the accel engine. Security naturally comes out of this. I have been
> 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. 

Please note, that the SGI gfx hardware helps there to quite some extent, and
you also have to care for broken PC style designs. The security design of
the SGI HW is much better than for standard PC stuff.

> RIght now if I where
> to start 3 OpenGL programs in X windows and if all of them bang on the
> registers at the same time it would surely hose the machine. A per process
> access to the accel engine needs to be set up. With /dev/gfx I plane to
> have so you allocate a window in the framebuffer for accel work. This
> enables you to use /dev/gfx with or without X windows with the same
> perforamce since in X windows you are opening /dev/gfx to work with a
> window instead of going threw the X server just like its done on SGI
> stations. Plus with the window idea you can mmap the zbuffer the size 
> of the window. 

This is not possible with all cards:

> Even if the card only allows a z buffer the size of the
> mode /dev/gfx will only mmap the window area of the zbuffer. 

No. Due to page granularity you will almost always have to map more.

> This way
> each window area can belong only to a specific process. The problem I'm
> have is with window overlapping. 

That is one point, where the SGI HW helps ... Individual windows have tags
in the graphics RAM that can be regarded as a kind of "stencil-mask" for
such clipping purposes.

Also they do not give you direct framebuffer access, as this gets in the way
regarding security.

> As for mmap the accel registers
> themselves. Well thats tricky. One we have to make sure the accel engine
> and the framebuffer are not hit at the same time. This is the hardest
> part since I'm no guru with the mmap system. 

There is a tradeoff here:

Doing mmap-trickery to lock out mmaped access while the accel is running is
possible, but has a serious performance impact.

Thus I suggest the following:

If the graphics engine can be _seriously_ (system locks up, graphics get
unuseable, ...) confused by simultaneous access, we should use forced
locking using mmap trickery.

Otherwise we should rely on advisory locking that will only access the
framebuffer after having acquired it thus flushing and halting the 
accel engine.

> As for mmaping dangerous
> registers well I was thinking of having a ioctl call that returns a map of
> the registers and need mask on these registers. So for example you have
> 
> struct gfx_registers {
> 	line_x 0x34;
> 	line_x_mask 0xff12;
> 	line_y 0x35
> 	line_y_mask 0xff13;
> 	...
>         ...
> }
> 
> Where line_x represents the offset from the beginning of the accel MMIO
> region. Feedback if this is a good idea. What I trying to do is provide
> the programs where to program and not to good into areas he/she shouldn't.

This is insecure. If a register is insecure, do not export it. Except maybe
to root or other specially priviledged users/groups that are trusted on
that. This way the X server can keep banging the hardware hard and direct,
while a "normal" program cannot do any harm.

> Hum. Can you expalin in detail the ping pong method. I sort of have a
> idea on how it works but not quite. Thanks.

Think that's through - right ?

CU, Andy

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