Cambridge CAP Computer Operating System, Study notes of Operating Systems

Download Cambridge CAP Computer Operating System and more Study notes Operating Systems in PDF only on Docsity!

o

PETER J. DENNING, Ed/tor

The

Cambridge

CAP Computer

and Its

Operating System

M.V Wilkes

R. M. Needham

THE COMPUTER SCIENCE LIBRARY

The

Cambridge

CAP Computer

and Its

Operating System

The

Cambridge

CAP Computer

and Its

Operating System

M.VWilkes

R. M. Needham

University of Cambridge

NEW YORK • OXFORD

NORTH HOLLAND

Elsevier North Holland, Inc. 52Vanderbilt Avenue, New York, N.Y. 10017

Distributors outside the United States and Canada: Thomond Books (A Division of Elsevier/North-Holland Scientific Publishers, Ltd.) P.O. Box 85 Limerick, Ireland

© 1979 by Elsevier North Holland, Inc.

Library of Congress Cataloging in Publication Data

Wilkes, Maurice Vincent. The Cambridge CAP computer and its operating system. (Operating and programming systems series) (The Computer science library) Bibliography: p. Includes index.

1. CAP (Computer) I. Needham, Roger Michael, joint author. II. Title. QA76.8.C16W54 001.6'4 79- ISBN 0-444-00357- ISBN 0-444-00358-4 pbk.

Manufactured in the United States of America

Preface

Work started on the CAP project in 1970. The initial planning was done jointly by

both authors, but as time went on itwas the firstauthor who assumed leadership

of the project and was reponsible for most of the major decisions. The origin of

the project lay in two visits paid by the second author in June 1968 and August

1969 to the Institute for Computer Research at the University of Chicago.

Professor R. Fabry, then a graduate student, was there working under Profesor V

H.Yngve on the design of a computer with hardware-supported capabilities. We

felt that this approach to memory protection broke new ground, and that it

should be followed up by building a computer on a sufficiently large scale to

support a complete operating system. As time went on the decision was taken

(by RMN) to base the design on implicitly, rather than explicitly, loaded capabil-

ity registers. This is perhaps the most distinctive feature of the CAP computer

from the hardware point of view.

Professor D. J. Wheeler took on his competent shoulders the responsibility for

the design of the CAP hardware. He was ably assisted by Mr. N.W. B. Unwin. Mr.

V. Claydon was responsible for the mechanical work, and Mr. D. B. Prince and

Mr. R J. Bennett assisted with the commissioning. It contributed immensely to the

success of the project that the design and construction of the CAP computer was

carried through to high professional standards and fully met its specification.

Professor Wheeler himself took a close interest in the project in all its aspects and

we have profited greatly from the continuing discussions we have had with him.

The CAP project was an exercise in the design of a coordinated hardware,

firmware, and software system. A number of proposals for the protection

structure were examined and it was decided to adopt one that had been worked

out in some detail by Dr. R. D. H. Walker in his doctoral thesis. Dr. Walker

remained in the Laboratory as a member of the Faculty and was responsible for

much of the implementation. In particular, he designed and implemented the

microprogram and the input-output system.

The choice of a programming language for an operating system is a crucial

one. Early in the CAP project two workers in the Laboratory, Dr. S. R. Bourne and

Mr. M. J. T. Guy, produced a compiler for a very small subset of ALGOL 68. It

Acknowledgments

We should like to express our thanks to our senior colleagues who have all

contributed to the project in some way or another, especially Dr. N. E. Wiseman,

Dr. M. Richards, and Dr. J. K. M. Moody. The project owes much to successive

generations of graduate students whose work and ideas have gone to make up

the system. Their names and those of other workers in the Laboratory who have

contributed will be found in the CAP bibliography at the end of the book. We

should like to add the name of Dr. J. Hext of the University of Sydney who spent a

year with us early in the project. We are also conscious of our debt to many

colleagues in other laboratories, especially to Professor R. Fabry (whom we have

already mentioned), Professor J. H. Saltzer, Dr. M. D. Schroeder, Dr. B. W.

Lampson, and Professor Anita Jones.

We have similarly received much help from our colleagues in the work of

preparing this manuscript. Dr. Walker read the draft carefully and saved us from

committing a number of errors. We have a special indebtedness to Dr. A. J.

Herbert: Not only did he read the manuscript and help us get it into its final form,

but he took responsibility for the production of the camera-ready copy for the

printer. Without his help there is no doubt the book would have contained many

more inaccuracies and imperfections than in fact it does. Mrs. M. K. Foale gave

us most valuable assistance in editing the text and in creating the computer

version from which the camera-ready copy was produced.

We are indebted to Macdonald and Jane's Publishers Ltd. for permission to

reproduce as Figures 1.1 and 1.2 two diagrams from "Time-Sharing Computer

Systems" by the second author. We are similarly indebted to the honorary Editor

of the Computer Journal for permission to reproduce as Figure 5.1 a diagram from

a paper entitled "Domains of Protection and the Management of Processes"

which appeared under our joint names in Volume 17, page 117 (1974) of that

journal. We should like to thank Dr. Herbert for kindly agreeing to our reprinting

in full a paper presented by him at an international colloquium held at IRIA,

Rocquencourt, in October 1978, and to thank IRIA and the North-Holland Pub-

lishing Company in Amsterdam for giving the necessary permission.

Finally, we should like to express our appreciation to Professor Peter J.

x Acknowledgments

Denning of Purdue University, the editor of the series in which this book appears.

Professor Denning has taken much interest in the CAP project from the begin-

ning, and it is due to his suggestion and subsequent encouragement that the

book has been written.

The design and implementation of the CAP computer and its operating system

was a departmental project in the Computer Laboratory of the University of

Cambridge. It received very generous financial support from the Science Re-

search Council of the United Kingdom.

CAP FUNDAMENTALS

Instruction register BASE-LIMIT REGISTERS

I'M • "

ENABLING FLIP-FLOPS

Read

Write

MODE FLIP-FLOP

Program counter

Setting of enabling flip-flops

Execution sequence: Set M = B+p ifp<L; otherwise trap Fetch instruction into instruction register Set enabling flip-flops from Cs Set M = Bs+a if a<Li; otherwise trap Execute instruction; trap if execution not enabled Increment p Repeat Trap sets mode flip-flop

Memory address register M

c,

R RW E

Read *

Write

Figure 1.1 A Protection Architecture Using Base-Limit Registers

CAP FUNDAMENTALS 3

words that go into base-limit registers are called segment descriptors, whereas in the case of the CAP and similar machines the base-limit registers are renamed capability registers and the words that go into them are called capabilities. A capability contains a base, a limit, and an access code.

Capability Architectures

In a machine with a capability architecture the memory thus contains words of two different types, namely, data words (which term includes instructions) and capabilities. In order to be able to access a segment of memory it is necessary to possess a capability for it. Protection depends on the fact that capabilities cannot be forged. It must not be possible, unless the necessary high degree of privilege is available, for a bit pattern to be generated in an arithmetic register and transferred, via the memory or otherwise, to a capability register. Thus while capabilities may be manufactured by the part of the system whose function it is to do this, they may not be counterfeited elsewhere. Data words and capabilities are stored in distinct segments and no segment ever contains a mixture of data words and capabilities. There are two different types of capability, namely D-type and C-tvpe. Possession of a D-type capability for a segment enables words to be transferred from that segment to an arithmetic register, or vice versa; possession of a C-type capability enables words to be transferred from the segment to a capability register, or vice versa. In the CAP it also enables certain digits in the word to be transferred from the segment to an arithmetic register, but not the other way round. The former involves no loss of protection, but it does enable the bits in a capability to be inspected. If the only capabilities that were to exist giving access to segments containing capabilities were of C-type and the only ones that were to exist giving access to segments containing data were of D-type, then the system would be intolerably restrictive. Relaxation of the rules is, however, possible in a controlled manner. For example, in the CAP operating system a certain procedure, responsible for performing housekeeping tasks necessary after the occurrence of an interrupt, is given a D-type capability for a segment containing capabilities. Elsewhere that segment is accessed by means of a C-type capability. Thus, although we may speak of capability segments and data segments, we do not imply that capabilities for them are always of a particular type. There must be one very highly trusted system procedure that has both a C-type and a D-type capability for the same segment. This protected procedure may be likened to the Royal Mint, since it may perform legally

CAP FUNDAMENTALS 5

what would elsewhere be an act of forgery; that is, it may manufacture capabilities. Figure 1.2, also taken from Wilkes (1975), shows the type of organisation just described. Loading of the capability registers may be done explicitly by instructions included for that purpose, very much in the way that index registers are loaded. Plessey System 250 works in this way. In the CAP computer loading of the capability registers takes place implicitly when capabilities are referred to. The capability registers form, in effect, an associative memory that operates in very much the same way as the associative memory used in a paging system. In the CAP and similar machines the rules governing the manipulation of capabilities are enforced by hardware. In systems of which HYDRA is an example, similar rules are enforced by software, the computer on which the software runs being a conventional one with a privileged mode. The fact that it is possible to implement capability systems in software should not be allowed to obscure the essential difference between computers with conventional hardware and those with capability type hardware; nor should the fact that base-limit registers and capability registers play a similar role in addressing memory.

The Control of Privilege

The conventional system with a privileged mode enables facilities for memory protection to be put at the disposal of the writer of the operating system. Similar facilities cannot, however, be put at the disposal of the designer of a subsystem (for example, a transaction processing subsystem, or a real time subsystem) which will run under the main operating system unless he is allowed to incorporate part of his subsystem within the operating system. Protection systems that have levels or rings of protection enable this difficulty to be overcome, provided that the writer of the operating system does not use all the levels himself, but leaves some to be used by writers of subsystems. In a capability system there is no difficulty in placing at the disposal of the writer of subsystems facilities which are exactly similar to those available to the writer of the main system. Moreover, they can be extended' if necessary to the writers of sub-subsystems. Furthermore, there is nothing hierarchical about capabilities, whereas with rings of protection a process has access to everything in its own ring and to rings outside it. It is this non-hierarchical characteristic of capabilities that is perhaps their most distinctive feature. A hierarchical organisation is appropriate to the management of the flow of control (since there must be some pinnacle of authority) but

6 CAP FUNDAMENTALS

it is unnecessarily restrictive in the case of protection. This fact must have become apparent to anyone who has tried to plan a system of locks and keys for a building with a master key, submasters, and so on. The realisation that a hierarchical system of memory protection is inadequate came almost simultaneously to operating system specialists and to programming language specialists. To the former one of the principal attractions of capabilities was that they seemed to lend themselves naturally to a non-hierarchical protection scheme. The latter took up ideas that had already appeared in SIMULA and other languages and generalised them under the name of abstract data types. Memory protection can be thought of in two ways: in terms of addressing or in terms of lookout. The former is exemplified by the scope rules of a high level language. A programmer has no way of addressing a variable that is out of scope; he may think that he can do so, but the identifiers that he writes under this misapprehension will be invalid and his program will be rejected by the compiler. Similarly, the possession of a capability for an object gives the programmer a means of addressing that object; without the capability he cannot validly even refer to it. On the other hand, in a programming situation in which all variables are global, the programmer may have accurate knowledge of where the various objects are in memory or know valid symbolic addresses for them. However, if he refers to an object in a part of the memory that is locked out, when the relevant instruction comes to be executed the memory protection system will produce a run time trap. There is a further requirement for an ideal memory protection system that has little to do with the original motivation for providing memory protection. This requirement is that at any time the running procedure should have access only to the data that it requires and to nothing else. Moreover, it should be possible by inspecting the program, or by examining a run time trace, to determine unambiguously which data are in fact accessible. Benefits flow from this both at the time when the operating system is being developed and when it is being run in service. During development a large class of program errors, namely those which lead to a procedure attempting to access data segments which it should not access, can be readily and surely located. When the system is put into service any residual bugs can similarly be found and dealt with in such a way that they are unlikely to reappear. At the same time, there will be a much reduced likelihood that they will cause widespread corruption of data held in the system. The same applies to bugs inadvertently introduced into the system when changes are made to correct defects or to introduce new facilities. If the effects of such

8 CAP FUNDAMENTALS

available to the process a regular capability for the segment specified by the enter capability. It will be seen that the sole use that can be made of an enter capability is to use it in conjunction with an ENTER instruction to enter the procedure to which it refers. The capability segment specified by the enter capability contains capabilities that are intended for use by any process that has occasion to run in the procedure, but only while it is actually doing so. There is no way in which the process can get access to these capabilities without entering the procedure. The code of the procedure must be so written that, at the time of exit from it, none of these capabilities are loaded in capability registers. In certain circumstances a simple jump might be used for leaving the procedure. This, however, would imply that the procedure was thoroughly trustworthy, since a jump to the wrong location could give rise to loss of protection. This potentially dangerous situation can be avoided if an ENTER instruction is used for leaving a procedure as well as for entering it. A procedure designed in this way may be called a protected procedure. There is a close parallel between protected procedures and abstract data types. In the CAP project these ideas have been developed further. A program is regarded as being composed of a collection of protected procedures, so that at all times the process is running in one protected procedure or another. It is moreover recognised that, in accordance with the principles of structured programming, protected procedures will be used in a nested manner; consequently parameter passing is implemented by means of a stack and there is a RETURN instruction that has the effect of restoring the situation that existed before the corresponding ENTER instruction took effect. The RETURN instruction is used for leaving the procedure instead of another ENTER instruction, and has the same property of preventing any leakage of capabilities from one domain to another. The fact that the system is designed on the understanding that the programmer will use nested ENTER and RETURN instructions to give a hierarchical organisation to the flow of control does not in any way imply a hierarchical protection system. In fact, as already pointed out, in a capability architecture the two functions of organising the flow of control and of providing protection are completely divorced. In the CAP, a protected procedure consists of code and data segments encapsulated so as to form a single object. Very frequently the same code segments or data segments are used with different workspace segments by a number of protected procedures performing similar functions for different processes or for the same process but in different circumstances. These are referred to as instances of the same protected procedure.

CAP FUNDAMENTALS

Protection Environment for a Process

There is in the above discussion an implicit assumption that one process only runs in the computer at a given time. Something more is required if it is desired to design an operating system that will run a number of independent user jobs at the same time. In such systems each user job runs as a separate process, that is, it has its own virtual processor. One of the functions of the operating system, or more strictly of that part of the operating system sometimes known as the coordinator, is to create a sufficient number of virtual processors from the limited number - in practice one or two - of real processors with which the system is provided. This it does by time slicing. Each process has its own process base, in which its status is recorded when it is not actually running in one of the real processors. The user processes may be regarded as subprocesses of the main process that runs in the coordinator. It is necessary to be able to give one user process privileges that are not given to another, and vice versa. Thus, on activating a user process, the coordinator must define a protection environment for it to run in. This environment includes all capabilities that the process will need, but in general, not all of them will be available to the process at the same time; as it runs it will move from one domain of protection to another, the changes being brought about by the execution of ENTER instructions in the manner described above. Having defined the protection environment, the coordinator must cause the user process to be entered. Return to the coordinator can take place either as a result of the process executing the appropriate instruction, or as a result of the occurrence of an interrupt or a trap. In all cases the status of the process must be preserved. It may be noted that in a capability computer there is more information to be preserved than in a conventional computer. When a process is entered from the coordinator sufficient information must be recorded in the microprogram memory to make the return possible. Specially microprogrammed operations must therefore be provided both for entering and returning from a process. The way in which this is done in the CAP system is described below.

Relative Capabilities

In a segment capability as so far defined, the base is an absolute address in memory and the capability selects a segment out of the entire available memory. Such capabilities may be called absolute capabilities. A natural extension is to define a relative capability in