masticol@cadenza.rutgers.edu (Steve Masticola) (10/25/90)
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)
strom@arnor.uucp (10/26/90)
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). All other things being equal, the finer-grained your firewalls, the better. The most common firewalls are the address spaces provided by operating systems---e.g. UNIX processes, Mach tasks, VM ``virtual machines''. These firewalls are effective, but heavyweight. Communication across address spaces is more expensive than communication within address spaces. It would not be practical to put each *module* of a large software system in a separate address space. 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. 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. *Typestate* checking is a dataflow technique which statically identifies which subset of operations on a particular data object are legal at which program points. When an operation is issued from an incorrect context, it is flagged as an error. 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. 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. 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. 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. -- Rob Strom, strom@ibm.com, (914) 784-7641 IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10958