zed@mdbs.uucp (Bill Smith) (10/28/90)
In article <1990Oct25.193935.375@arnor.uucp> strom@andreadoria.watson.ibm.com (Rob Strom) writes: > >In article <Oct.24.22.04.05.1990.393@cadenza.rutgers.edu>, masticol@cadenza.rutgers.edu (Steve Masticola) writes: >|> Can anyone help out with a reference to "firewalls"? A professor here >|> says they're a modularization structure which is intended to stop the >|> spread of error effects within a software system. Unfortunately, he >|> doesn't remember where he saw the reference. >|> >|> Thanks for your help! >|> >|> - Steve (masticol@athos.rutgers.edu) > >I don't know if this is the reference intended by your professor, but I used >this term in my paper with Shaula Yemini, ``Typestate: A Programming Language >Concept for Enhancing Software Reliability'' (IEEE Trans. Software Eng., >SE-12, 1, January 1986). > >As you point out, a firewall is a form of protection. If programs A and B >are running together on the same machine, and program A contains an error, >it is desirable to confine the effects of the error so that program B >is not affected. Having firewalls improves reliability (since program >B will still work), security (since program A cannot sabotage program B), >and problem determination (if program A misbehaves, I need not search >in B for the possible cause). I find this an excellent philosophy for life under pressure although I haven't empirically determined it's worth. It might be too rigid for me, personally. (Of course, I'me too rigid for me, personally too. ;-) The idea I mean is that each person has to have their own private self that they keep alone from anyone else. In this way, they become one with their private self and are able to keep it in whatever shape that want to. "Give me some space." is a slang equivalent to "You're trying to beat on my firewall. Let me keep myself reliable so that I'm able to be of use to you when you need me. I still love you, but everyone has their limits too." >All other things being equal, the >finer-grained your firewalls, the better. Each firewall should be set according to the desires of the one they protect. If a program doesn't work with big, cement firewalls, then it shouldn't have them. "Tear down the walls." But, the walls have to be there until every works the way the program requires. >We would ideally like firewalls to have a granularity as small as a single >module, but without any performance penalty. Our approach is to >rely on compile-time checking to detect those kinds of programming >errors which, if undetected, would result in undefined, >implementation-dependent side-effects on other modules. Well, run time checking will always be necessary. Someone might spill some some Coke on the motherboard. (or spill some coke down your nose... ;-) You don't know what might happen, so it's hard to be able to have a program without some run-time firewalls, some boundaries that are always set to prevent it from hurting itself by reformatting the hardware. This is the essence of fault tolerance. >Conventional type-checking is inadequate, since >many program bugs are the result of issuing otherwise correct operations >*in the wrong order* --- e.g. storing into a buffer before it has been >allocated. A program has to be willing to work with the operating system first, then with itself, not the other way around. If you don't know your own software, how can you be sure how you relate to the operating system. I think I know myself, but do I really? How can I KNOW myself? I don't know what I'll do next. I pray that it will be good for me and good for others, but I must take a leap of faith that the OS has been designed by a good OS development team. Even if there is "proof" that my program and the OS work together, I'll still have to take a leap of faith to accept the proof, the proof system or whatever it is that makes me sure. >*Typestate* checking is a dataflow technique which >statically identifies which subset of operations on a particular data >object are legal at which program points. Personifying this technique, what I'll do is (somehow) find out ahead of time a set of rules that each person (program) needs to keep his or her firewalls in good shape. These rules will have to be appropriate for a particular data object (person) and chosen by that person (program points). The typestate (person) is up to the situation at a given time to follow to maintain reality checks (assertions in CS lingo) so that if a violation occurs somewhere, the firewall may be activated in its pure force to support a safe landing and prevent program (program) crashes. >When an operation is >issued from an incorrect context, it is flagged as an error. I will complain if you hit me, but is it an error? Only by examining the context will we be able to know for sure. Until you are able to read my mind without even looking at me (I hope you will soon) you won't know my context. >We incorporated typestate checking in an experimental language called >NIL (Network Implementation Language), and in Hermes. In these languages, >any module which successfully compiles is guaranteed at execution time >not to corrupt other modules, even if these modules are running in the >same address space. We thus get the effect of fine-grained ``firewalls'' >between modules without the performance penalty. Modules belonging >to different applications can safely coexist in one address space, >but can communicate as cheaply as modules of the same application. >As an additional benefit, we catch an additional class of programming >errors at compile-time. Wow! I am impressed with your creativity. Please do not send me any information about the implementation details of your project so that I am not obligated to IBM for possible infringement unless you have patented these ideas. >What do you give up to get typestate checking? First, typestate checking >requires that any aliasing of variables be detectable by the compiler. >As has already been discussed on comp.lang.misc, Hermes is a pointer-free >and hence alias-free language, so this requirement was already met. >Other languages would have to be restricted to meet this requirement. What is required is self-discipline not laws and restrictions. >Second, you have to structure your program to avoid ambiguous typestates. >For example, a variable which is initialized on some paths to a >statement and uninitialized on other paths would have to be explicitly >declared as a variant. Life does not seem to have these requirements. All names (aliases) belong to God who prevents the confusion that could result from literal interpretation of each sound uttered. >In our experience, the potential for >error detection, the gain in efficiency of cross-application communication, >and the security/reliability/debugging advantages of firewalls are >benefits which are well worth the costs. Ambiguity is inherent in life. Life is without price. >Rob Strom, strom@ibm.com, (914) 784-7641 >IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10958 Bill Smith pur-ee!mdbs!zed [Specific disclaimer: The use I would like to put these ideas is not part of any project planned by the management of mdbs Inc.]