More info about the vidram board

[Brian D. Botton]

In article <574 at limbic.UUCP> gil at limbic.UUCP (Gil Kloepfer Jr.) writes:
>To keep with the subject at hand...there *IS* a security risk in using
>the vidram board-- A user can write a program to scribble all over
>your video RAM, causing your screen to be (at worst) unreadable.
>However, most UNIX-pcs I've seen have /dev/console unprotected, and
>writing to that will have the same effect.  Most UNIX-pcs aren't
>open to untrusted users, and thus this point should be moot for the
>most part.  (Lenny still threatens to call my system and turn all my
>characters upside-down, but that's another story :-)

  In one of my early postings I did mention that the video ram is wide open
to any process on the system.  Personally, I don't think this is an issue.
All that can be stolen is what is on the screen right now.  The same goes
for what can be corrupted.
  My machine, bilbo, is hooked up to a modem for uucp traffic, but Brad Bosch
and I are the only people with accounts on it, and yes, root and install are
password protected.  So if you are worried about people copying from the
screen, don't let them on your system.

>ALL screen support is lost with the hardware mod -- that is to say,
>in order to implement any kind of window manager with the hardware
>mod, it will be your own responsibility to draw characters (fonts),
>do graphics, handle window boundaries, perform scrolling, etc.  This
>sounds simple on the surface, until you think about the code required
>to scroll a part of the screen...  It's a complex memory move.

  That's right, bit-blit routines are complicated.  The original bit-blit
routines for Mgr were written in assembly for Suns.  Brad and I are using
the portable C version, which does have some performance problems.  These
routines take care of displaying windows, fonts, icons, etc., all of which
are from Mgr, not from the standard window manager.  The X people will have
to deal with these problems as well.

>
>> Is there some reason why you just can't do this by clipping one line
>> on the motherboard? (somewhere is there a VIDMOD* line that indicates
>> if the video is being modified?)
>
>No.  This was discussed in the net in detail, but in summary if you
>clip this line, you disable all memory protection and can scribble all
>over the running kernel if you're not careful.  I, personally, would
>like to be protected from that :-)

  The whole reason for the PAL is to make sure you are addressing only
the video ram.  If you don't have hardware memory managment to ensure that
processes are protected from themselves and to protect the kernel and devices,
you might as well not bother with Unix.  In fact, if the 3B1/7300 didn't have
hardware memory management and demand paging, I wouldn't have even considered
buying one.

>I believe that there is only a partial-kit available now.  My recommendation
>is to write to Brian Botton directly at laidbak!botton or laidbak!bilbo!brian.

  Yes, all I have left are the partial kits, which are ready for shipment as
soon as I get a little free time.  The rest of the parts are quite easy to get.
The only reason I'm not providing them is it takes a surprising amount of time
to order, collect, and distribute them.  If the X people ever get to the point
of releasing their port, I'll reconsider.
  If you want info about the kit, or copies of my origianl posings, let me know.
The partial kit includes a PC board, a programmed PAL, and revised instructions.

  BTW, I am caught up with all shipments that I had orders for.  If yours still
hasn't arrived, send e-mail.

Brian
-- 
     ...     ___	  _________
   _][_n_n___i_i ________ I       I		Brian D. Botton
  (____________I_I______I_I_______I		laidbak!botton  or
  /ooOOOO OOOOoo  oo oooo  oo   oo		laidbak!bilbo!brian