Lawrence Robinson

Proof techniques for hierarchically structured programs

A method for describing and structuring programs that simplifies proofs of their correctness is presented. The method formally represents a program in terms of levels of abstraction, each level of which can be described by a self-contained nonprocedural specification. The proofs, like the programs, are structured by levels. Although only manual proofs are described in the paper, the method is also applicable to semi-automatic and automatic proofs. Preliminary results are encouraging, indicating that the method can be applied to large programs, such as operating systems.

Proving multilevel security of a system design

Two nearly equivalent models of multilevel security are presented. The use of multiple models permits the utilization of each model for purposes where that model is particularly advantageous. In this case, the more general model is simple and easily comprehensible, being more abstract, and is useful for exposition of the meaning of multilevel security. The less general model relates well to design specifications and permits straightforward proof of the security of a system design. The correspondence between the two models is easily demonstrated. The two models when applied appropriately are more useful for defining and proving the multilevel security of systems than existing models. The utility of the two models and their relationship to existing models is discussed and the proof of the security of one particular system design is illustrated. The technique for accomplishing the security proof is straightforward and can be extensively automated.

An example of hierarchical design and proof

Hierarchical programming is being increasingly recognized as helpful in the construction of large programs. Users of hierarchical techniques claim or predict substantial increases in productivity and in the reliability of the programs produced. In this paper we describe a formal method for hierarchical program specification, implementation, and proof. We apply this method to a significant list processing problem and also discuss a number of extensions to current programming languages that ease hierarchical program design and proof.

On attaining reliable software for a secure operating system

This paper presents a general methodology for the design, implementation, and proof of large software systems, each described as a hierarchy of abstract machines. The design and implementation occur in five stages as described in this paper. Formal proof may take place at each stage. We expect the methodology to simplify the proof effort in such a way as to make proof a feasible tool in the development of reliable software. In addition to the anticipated advantages in proof, we feel that the methodology improves a designers ability to formulate and organize the issues involved in the design of large systems, with additional benefits in system reliability. These advantages remain even if proof is not attempted. We are currently applying this methodology to the design and proof of a secure operating system. Each level in the system acts as a manager of all objects of a particular type (e .g ., directories, segments, linkage sections), and enforces all of the protection rules involved in the manipulation of these objects. In this paper we illustrate the methodology by examining three of the system levels, including specifications, for a simplified version of these levels. We also demonstrate some proofs of security-related properties and of correctness of implementation.

Writing Simulatable Specifications in SPECIAL

It is commonly accepted that most software systems contain large numbers of errors that are not detected until delivery and testing by the customer. Some studies have determined that errors are most likely to be introduced in the design phase; perhaps up to two-thirds of all system errors are design errors. Formal specifications can be a useful vehicle for exposing design errors by forcing attention early in the system development process on “what the system should do.” Although specifications are an improvement over, say, natural language for describing systems, even if carefully read they cannot be expected to eliminate all design errors. Fortunately, because specifications are supposed to be complete, it is in principle possible to execute them with test data exactly as one would execute code. We call such an execution of specifications module simulation, where the module is assumed to be the unit that is specified.