gil@limbic.UUCP (Gil Kloepfer Jr.) (10/26/89)
Since my posting a week or so ago, I've gotten many requests for various information about Brian's vidram board. I'm flattered to have so many requests for information about this when I am really only a satisfied customer :-) . In any event, in an effort to help answer some of the questions being asked of me, here are the answers to some to date: > >From apple!denwa!stb!michael Tue Oct 24 06:36:58 1989 remote from ames > Actually, I think I've managed to find all the security holes Side note-- I'm sure that there's *someone* on the net who can show you that you've missed a couple... :-) 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 :-) > Bypass the window driver and talk directly to the screen. I thought > that was the purpose of wrastop() no, it isn't. wrastop() allows direct access to the pixels within a window. It is a controlled access to the screen memory through the window driver. Unfortunately, the way wrastop() is implemented (as an ioctl() to the window driver), it is slow and is written fairly crypticly (is this a word???). > it, you lose font support that way See my facedisp program for the UNIX-pc (to display the FaceSaver files). This is a perfect example of how text and graphics can live in the same window at the same time using wrastop() and plain write() calls. You don't lose font support at all with this. > but then you also lose font support with the hardware mod if you > clobber the screen 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. > 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 :-) > From: ames!gatech!mcnc.org!bacchus.uucp!darren (Darren Friedlein) > Who can I contact for info on how the X port is coming? As I recall, John Milton and Alex Crain showed an interest at one time in porting X to the UNIX-pc. That line of discussion kind of fizzled out, but I'm hoping someone starts talking about it again. I, personally, do not plan on getting involved in the X port simply because I have neither the time nor the interest, but seeing the port would be neat. If I plan on doing anything postable with the board, it will be along the lines of a daemon-based window server (rather than a driver-based one, as currently implemented) which will perform some functions a little better that the current window driver (such as icon control), and will provide compatibility with the current driver so that things like the voice power voice editor won't break. Before I get swamped with comments about it being slower than the window driver, I know. However, watch your modem's send/receive data lights when you are doing a uucp transfer and then see what happens when you "cat" a big file to the screen. > From: beau.adp.wisc.edu!davew@cs.utexas.edu (Dave Windorski) > I didn't get to see previous postings on this and I am wondering how I can > get this kit? 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. Most of the questions I've gotten to date are along these lines. I hope that these answers can be of help to someone, and if John or Alex are out there reading, maybe they can post an update as to what's happening with the X port, if anything. I remember there were some real problems with doing the port, and both of them are too busy to be spending all their time trying to solve this problem! Gil. ------ | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | ...ames!limbic!gil
botton@laidbak.i88.isc.com (Brian D. Botton) (10/30/89)
In article <574@limbic.UUCP> gil@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
wjc@hoswjc.ATT.COM (Bill Carpenter) (10/30/89)
In article <1989Oct29.221139.17835@i88.isc.com> botton@laidbak.i88.isc.com (Brian D. Botton) writes: > 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. I think this is worth kicking around a little, since only the bad guys/gals think of everything when it comes to security. Since security is not too much to brag about on the UNIXpc, I think we should at least conclude that we're no worse off with the board in than we were before. (As opposed to, "we're a little worse off, but we don't care".) 1. STEALING THE SCREEN: There probably isn't much difference here. There is an ioctl() to get a dump of the screen contents anyhow. I don't know if it is shrewd enough to notice if you're logged onto the console when you run it, but I'd be surprised if it did. So, if you type your password onto the screen, I guess the crooks can get it without the hardware mod. 2. WRITING THE SCREEN: When you login, you can do "mesg y" to prevent someone writing to your login window. However, as far as I can tell, other windows (and windows being used by phone manager, etc) you open are root/sys/666 (in other words, wide open to all). So the difference here is that without the hardware mod, you have some control over writes into your login window. Does write access to a window matter, if you don't give out read access to the keyboard for that window? Well, in your classic spoof, you throw up a password prompt and read the keyboard while somebody types in their password. With the UNIXpc, you could bitblit up a password prompt and then (since you didn't turn echo off) bitblit the password back off the screen. This would take some large, but not impossible, effort. Also, it might not fool too many people. (For extra credit, bitblit each character as typed and then blank it out on the screen to simulate no-echo.) If I were trying to pull this kind of spoof without the hardware mod, I guess I would open a borderless window just the size of the prompt and position it in the right place on top of the user window. From there, proceed as before. So, I guess this breaks even, too. What else? -- Bill Carpenter att!ho5cad!wjc or attmail!bill