A template for rapid prototyping of operating systems - IEEE Computer ...

A TEMPLATE FOR RAPID PROTOTYPING OF OPERATING SYSTEMS’ Myla Archer

Deborah Frincke

Karl Levitt

Division of Computer Science, University of California, Davis Abdract. We believe that rapid prototypii of many classes of syetems can be facilitated by start ing from an executable template speci5cation appropriate to that daw. A system template serv- several useful purposes. It organi~esones thinking about the particnlv system to be specified, and speeds the epeciflcation proceas by pre-specifying strncturea and operations common to all system in a class. If exe cutable, it can be developed into a aptem prototype. Though beyond the scope of this paper, it can organice proofs of properties of the qxiflcation and ita implementations by making it possible to isolate the relevant proof obligations. our templates have UL additional p r o m they classify mbspec%cationa according to “kinds” that need to be completed differently. We illustrate rapid probtyping from a template for operating systems, specifically showing how to obtain a rapid prototype of the MINIX system. We believe that this approach may also be nsefnl for other dasses of ayetem, such 89 architectures.

1. A generic specification for an operating system With the idea of providing a general tool for the rapid protoot)-pingof operating systems, we have developed an executable template operating system rpecification that can be specialired to describe a large variety of aystem. We set the template M serving several purpoees. Firat, it orgsnires one’r thinking about the workingn of an ( a l m d ) arbitrary system by factoring it into ita componenb playing conceptually Merent roles, and relieving one of having to specify c e r tain high-level operatiom. Second, when compkted (or even only partially completed) for a specific application system, it can be ased M a rapid p r o t o m of that aptem (or part of it). Finally, it can be wed to o r g b prooh of p r o p e r k of any application aystem, by helping to isolate for each property junt those M P C C ~of the @em that are relevant, and thas potentiaIly Simplifying actual proof obligadons. Thh paper b concerned with the first two purpceen. Ideally a “rapid prototype” CID be w d in place of a yet to be implemented “real” operating sfstem, the two sfstem behadng i d e n t i c e in rll dtrutions. The rapid p r o t o w obtained by completing our template specification u e intended to hare tanctiond behavior identical to a fully implemented operating system, including m m &, sign& and interrupts. Such a p m t o m can be used to determine, among other thinga, whether the following are accnrateb represented in the design: 0

Is the sfstem btcure with rwpect to an external p o b ? Security flaws associated with incorrect qnxXcation of the myatem CA can be detected.

0

Do the sfstem c a b exhibit the functional behavior intended by the user? Based on Msamptions on the time reqrJred for operating qstem to execute, ia the overhead awociakd with the operating irptcm acceptable? can be used to kst out the functional behavior of the operat ldgh-krel performance behavior.

Consequently, the rapid proto+ ing system and simalatt

Operating uystems are ideal for the rapid prototyping approach we are taking: inatantiation of a template operating @em npecification.

This work w u partially mpported by the Rome Air Development Cenkr mdu Grant stitute of Technolog.

TH0380-6/91/0000/0119$01.OO 0 1991 IEEE

I IC)

-hom the Georgia In-

0

Operating ayatems are large programa and error-prone.

0

Errore in operating &stems have serious consequences.

0

There is significant commonalib among Merent operating systems. Most operating syetem can be viewed at their interface m manlrging collections of resources. MO= aver, such resource typea as proce%ses, sea, memory segmenb, schedulere, m q e a are common to almcmt all operating systems.

The general view of an operating system M an interpreter of asynchronous requesb systems,intempt driven underliea all operating aptems including multipr~g~&g, ey~tems,and distributed a p t a m . The principal parta of our template specification are abstract resources that are accessed by requesb from proceaxs, the requesb coordinated by a scheduler. An abstract access control mechanism decides whether the requesta are to be allowed. At the higheat level of the template speci6cation is a data Qpe which we call SFUvl (for Secure R m m e h4anager), whoee memben are operating ayetem in particular dah. An SRM is made up of a number of componenta M indicated, there w i l l be a aystem State, but there wiU also be a met of (uaer and ayatem) operations, a scheduler, an internal accesa policy (generally intended to implement oome UternSnr described securib policy, and hence called a Secpol), and a command interpreter for translating high-level operatiom and their argumenb, such as might be known to a user, into operatiom and argumenb meaningful on the system leveL The &nce of an interpreter component also providea the poseibiity of increasingly her-grained interpretation of operations into sequencea of other operations. The ayetem State contains ayatem configuration information: memory, proCUIBOH, 1/0 devices, and the atatea of these, M well M current proceate~,enqueued requentu, and a ryskm Wry. We will ray more about the uigdcance of the components of an SRM when we discum how the template can be elaborated into many different ayatema. The rpecfication knllruge we we, that of the hid algebra method of -83, KJA83], makea it ~ t a r d to think of the inhabitanb of data types, for example, an element of oort SRM, aa c o d d h g of a tupk of componenb; we begin by drrifping thtr with a brief d w of the method. We then give the details of our template qeciflcation, and illustrate the proceaa of ~idirhg it, d n g MINIX [Tanen871 M our example. MINM (Miniature b almost all of the aptem &, but a rady b p l e r implementation. MINIX mpporb wer and ayetem p " a which eommunicate through measage plssing; in thb me=, ib model of i m p b mentation b more that of a distributed system that ia d to realise a conventional multipm grumhg Nut, we will discaa how we belim the mame procem could be applied to obtain rpccMutbm for ptem of arbitrary c o m p w , including concurrent rJakm, and dcacribe how we apecf particular rpecihatiom to be ased an rapid prototypes. F i , we will bok at future directio~for our work. 0

m)

2. Writing final algebra specifications: the methodology Despite ib name, the fina algebra specihtion method b not what is generally considered to be an algebraic method; rather, it is operational. It reprwenb elemenb, wentially, by their observable behavior. T ~ Ma,met S of objecb of sort Elt m represented by a map lrom the carrier of Elt to Book thin map determines for each e of oort Elt whether it b a member of S. If the operation for obeerring membership is named isin, then the map corresponding to S b the aame aa the map on elemenb e of Elt obtained by holding S constant in the expression iSin(S, e). In general, an element of an abstractly specified sort I will be represented by a tuple of m a p (some of which may be Gary, and hence "map" only by courtesy). Each element of the tapk wiR correspond to an operation on ekmenb of oort e in malogy to the way a map from Elt to 1corresponds to bin: it is obtained by holding the ekment of sort I constant while kttbg the other argumenb of the operation vary. The operations corresponding to tupk componenb of ekmenb of sort s form the dwtinguwhing ret for the oort a. Thus, the distinguishing set of the sort SetofElt consisb of the single operation bin. To give a h a l dgebra specification of an abstract data type, one must k t determine the

I'

operations in its diatinngniehing eet. Any choice of distinguishing set operators leads to a representation of elements of the specified sort as elements of a product space; this represent& tion then permits one to define the value returned by an operation M a tuple whenever that value is of the specified sort. There is no h e d recipe for Snding the distinguishing set, but there are some huerietics. In some caaea, what certain components of this product space meet be is clear. For example, it was clear to UE in writing our generic specification that any SRM (secure resource manager) must have, among other things, a State component, a Scheduler component, and a SecPol (security policy) component. When this happens, it is clear that there d l be companding &tingaishing set operations that yield these componenb. In the case of an SRM, we have chosen to call them stateofSRh4, SchedofSRM, and polorsRM. In other cases, one thinlrs in the other direction, and sttarb from the operations to get the product space representation. A typical example of this is an abstract sort StackofElt, in which one realises that two stacks behave the same if one geb the same thinga by reading their top and by popping them. This leads to a (recursive) representation of StackofElt aa a product Elt x StackofElt. As we have indicated, once one has determined the tuple representation of elemenb of the sort b e i i specified, one can then delhe certain of the operations that return values of thin sort - the constructor operations - by giving their results an tuples. All other operations mnet be defined in terms of these C O I M ~ ~ ~ C ~ Othe H , distinguishing set operations, and the rieible operb tions f“,other data type specifications, using no tuples. As a corollary of this requirement, tuples may be used to exprese elemenb of any sort only b i d e the specification of that sort. We have found final algebra specifications relatively easy to write, more natural than initial algebra specifications. One can often think of the distingnishiry set operations aa behg neceb and d c i e n t to characterise the etate of any object b e i i specified Accordingly, the ~ H , heart of the specification, b achieved by indicating the specification of the C O M ~ ~ U C ~ the effect of each constractor on each operation in the d M n g u W q act. Engineemfamiliarwith writing rpecifications for sequential circuib will note that, emen-, a circuit’r tuple repnsentation b the oet of state variablca, and the qeciilcation, a eoneCtion of excitation C C ~ ~ defining the nextdate values for each etate variable in t e r m of the current state and input. In the next section, we will b t dcacrii the generic SRM apedcation in krnur of the p m duct apace representations of certain find sorb, and the row and operatima that will rhraya be present. We will then deecribe in some detdl how it mpeciabca to dcacrii and prototype the MINM aystem, and indicate how it could be rpecldiKd to dcacribe other eptema of almoat arbitrary complexity. We h i a h thb rection with a brief dwcription of the noktion and convcntionn ased in our rpecificationn; these arc M in the FASE qdem M d e a c r i i in Each epecification begins with the name of the sort be3ng rpeeUed, fobwed by a declaration ~ ~arities; this b called the &nature oection. If there are any O ~ C P ~ ~ ~ in O Ithe M of o p e d and all AUXILIARY OPHUTIONS section, these are availabk o e inaide the given @cation; other operatiom are &%le operatiom, and may be d by p r o g r m (iicluding other epecificati~~). Following the &nature section ia the list of those declared operatiom that conetitute the di&&dhg OCtN -D net operations do not require explicit de8nitbm. To compute the application of such an operation to a lint of ugnmenb, one extraeta the (unique) argument of the epccified sort, and applies the c o m s p o n h function in ita tupk to the r e m d d q argumenb (a trivial application if the tuple function b 0-ary). M other O ~ C ~ O Mhowever, , require definitions. Tuples in these definitiom are indicated by quare bnclreb, their elemenb acparated by commas. 0.- functions inside tuples are rimply &en Y e x p d ~ For . functions with armmenta, the notation “ I-> * * ” can be read M “&b. * * * With regard to error values, there b an error value of each mrt, together with a hidden element of the distingnishing ret that detecb it: thw, there Ir an errSRM and an iserrSRM, etc.. Function definitions are strict with nspect to e m . Occasionally, the specifications will include definitions of the form iserrTypc(op5pe(arge)) => ; theac arc translated M a prefix to the definition of opTypc which, when satisiied, cawen opTypc to return an error. is need for and, “ I” for or, “”” The following notation is used for b l e a n operations: “t”

WM].

-

”.

-

~ O M

for not, and for eqType for an appropriate choice of Type; these have the usual pncedences. Note that in the caac of =, except for a primitive aort Type, it is not required that eqTppe be a true equality relation, but only that it be uplicitb defined and have the appropriate arity (except that the system forces eqlrrpe to correctly detect equality to errType). ((=”

3. The template specification We initially envisioned that a template specification would CO& of certain k e d , nnchanging data trpe ~pecifi~atio~, defined down to the level of certain mbuidhy sorb,with the nub& diary aorta being &wed variable specifications whoe dewould depend on a given a p p b

that the sorb specified in the tion. However, it became clear to w in the rpecification ptemplate wodd be of three kinds. Having three kin& of EPCC&&~OMm e a a number of important purpoeea. First, in compIeting the template specification, the designer would d e few cfi m y ) chsngm to the specifications of the h u t kind, more to thoa of the m n d kind, and the moat to those of the third kind; thw the b t kind can be considered the mod generic of the specZ~ationS.Second, the deign decisions considered in each kind are in some sen# more general than thoee wnsidered in this mceeesor. Third, there is a hierarchy among pro+ that can be verified for a specification of each kind that will apply to to all Specificatiom that wmplete it. We call epecificatbna of the Grsf Irind, “6xcd”. From a de+ etandpoint, the 8pecificatio~ of the Grsf kind declare the major objecb of a generic operating m m and basic operatiom on these objecb. For exampk, objects will have ida and an &tract date. Earentially, t h e ~ p e c i f i ~ ado t i not ~ ~ change kom one application to another. For convenience, we allow OF tom derived from thoa in the epeci6rfion to be added; thL can wmetimea help abbreviate d e h h n a peculiar to a particular appbtion. In b d @CAM, the reachable carrkr of the rpecXed mrt (that is, the rot of dements of that mrt that sre v&ea of tern) b fixed nktire to thoae of the wrta in ib repmentation. Hence, any propertka proved h m the general apecXertion h u t dl reachable ekments d the rpeJfied rort, ~7 by rtracturd induction, will hold in any application. We edl ~ ~ p ~ i of i h thetmmnd i ~ ~kind “ b d reprerenktion” ~ B & M . From a deaign rtandpint, the objects in thb kind will have an htract mpedcatbn that cm be viewed U 8 model for more applkation-qede ~p-ktionr to h h in the third kind. For exampk, the occurity p o b is declared here to modd the standard reference monitor pDEN821: A requad Ir honored, denied, or tnndormed d e p e n m 011 the identity d the &r and the atate of the object. The template r p e c w .t thb level contab just the buabonu collection of opem tors. The designer b fra to p d e Me own operatiom p d e d t h q cm be upeciiled according to the reprawntation in the template. The# rpeJfiertbnr will a rort of &ad name, and rrill have a k e d Ed of ret o p e ~ l u of &otd arity. An a d t , the reprerentofionof the specified mort will be fired nktire to thoee of the aorta in its reprwcntation. Any proper& of element. of mth a rort that t .be ~ p m e d without structural induction mer the erniV of the rort will rtin hold in any applidbn. SpecE&~ of the third kind are “Wmbdpahd’ rpeeifierfioar. !J?hwrpeci6cationa capture the application-qxdc d e c b m . The dcaigner im free to change the representation of the objecb and to provide new opedone. These q d h t b m , at the v e q least, guarantee the cxiatence of a rort of the rpecEed name. In general, certain opentionr of a certain uity mud be pre#nt. Other than there Ir no restriction on how the operatom are defined. The# ~ p ~ i t i e a tare i o ~dmilv to the parameter part of puametuired rpecifi&i~~which occur in other @&n h q p a g a (e.g., that of OBJ [GMF’83]) In F i 1, we Ibt the rorta pment in our template, md intheir rpecification kind and (00 far aa ie h d ) thek represenktjon in k m of other aorb. In F v 2, we indicate the names and uitiea of &oed operatom in the specihtbnr of LinQ 2 and 3. The compkk upccification can be found in WOO]. In any application, of w m , there will be additiod oubsidiary data trpe Specikationa that are application epeci6e. The s o h epec%ed by these need not appear in dl applications.

*

de,

I22

N o r m e , they are required in order to completely define the representation and operations of sorb of the third kind, or of other application specific coorb. we d l discaes in acetion 6 exactly how we expect to aee a specidiration of this template M a rapid p r o t o w . Here,it is worth pointing out the heart of the rrpecification, namely the definition of the operation stepstate:

stepstate :State x Scheduler X Interp x secPol-+State

(S,9cH, r, P)=> kt R be getreqSchedder(SCH,S) in let SS be updhiststate(R, [objsofstate(S),p”csofState(S), getreqlisScheduler(SCH,S),

*pstate

histOrstate(S)]) in let RR be getnqsed)ol(SS,R,P) in kt RRI be getreqInterp(SSJtRJ) in let f be opofReqnest(RRI) and A be srgsotRcquest(RRI) in apSRMop(f,SS,A)

This definition shown how we expest the Scheduler, SecPol, and Interp componenb of an SRM to interact during the operation of the ayatem. The Scheduler eramines the State, especially the Requeatlist, to choose the next Request to be handled. The RequestList component of the State is e i m u l t a n e o ~updated; it may be the original RequestLi with the chosen Request nmoved, or it may be comething more complicated involving a reamputation of priorities, for exampk. The &tory component of the State b rbo updated. T h e Request b then passed by the M o l , which may retarn it unchanged, or may dter it (a dmple example b e i i to repbce it by a nnlIRcqaest if the Request t didowed). The redtbg Request b then p-d by the Interp, which may perform mch operatiom UI t r d t h g ‘’rehtive” arguments in a uaer’r request into “ahlute” aqpmenta known to the @ e m , or make other, more complex changa (e.g., rehement, U in WiW]). F i , the operation in the resulting Request b applied to ita ArgLbt, with the updated State U a hidden argument. We beliere that thia operation, with appropriate detinitiOm of the Sehedukr, SecpOz m d Interp, b &cient to describe thoee incremental O ~ ~ O of D aE general qdem not involving the receipt of i n “ i n g new R e q u d We d l discum thia in more detail in mtion 6. SORT

KIND

REPRESENTATION

1 1 1

t t t t 1

t

a 1

t a 1

a a

1

a a a

Plgure 1. Template rorb and their nprescntationn. I23

SORT

KIND

FMED OPERATIONS AND THEIR ARITIES

Scheduler

L

fetreq- (Scheduler X S k t e

b h P Sccpol

L

*-

=Mop

2

ObjatPred Object

a

ProccaPred Procar

1

2 2

Repat

a a

-v

a 5

Objectld

P r d

a a

-+ Requat), getreqlt (Scheduler X State -t RequatLirt), null- (+ Scheduler), triv- (48chedulu) fetreq- (State X Requat X l n h p +Repeat), tzk- (-+ Inkp) (StJc x Request x SecPol-+ Bool), getreq- (St& X Requat X SecPd --., Requat), n e (+ Sed’oI), r e d a t r a n t (-+ SecPol) name- (8RMop -+ Symbol), ap-(SRMop X Statu X ArgLirt -t State), eq- (BRMOp X BRbQp -+ Bool), NO-(-+ BRMop), &up-(+ SRMop) ap (0b)sCtpred X Object +Bool), triv- (Bod +ObjectPred) idd- (Objscc + O b j ~ ~ t I d ) q+( P r d r e d x P m e u -+ Boo$ triv- (B..I+ProceuPred) idd- ( P m -+ P r d ) opoa- @quat + SRMOp), upof- (Request -+ Ardht), proddof- (Requat +P r d ) , null- (+ Request) init ( S b b -+ HLtoq), W m d - M a t X H L w +Hirt0r;Y) objidof- (Arc+ObjatId), proddot- (Arg -+ Procald), objidb (ObjatId -+ Arc), p r o d d b ( P r d -+ Arc) cq (ObjeetId X O b j d -+ Bool), picudet ( O b j d X O b j d d -+ Bool) cq ( P r d X PKKcuId +BooI), p r d e t (Prou!nId X Proceuld -t Bool)

Figure 2. Prefixes of k e d operations for kind 2 and 3 sorb.

4. Elaboration of the template: MINIX The following general procedure can be followed to yield a epecihation of almost any syutem. B a s i c e , one compleks the kind 2 e p e c i 6 ~ a t i oby ~ adding the appropriate constructor or constractom; in the proeees, one h d a out the structure of the sorb haring kind 3 qecihatiom, and the ~petationrneeded in t h e qeci&atiom. In the protea of elaborating the kind 3 qecihatiom, one c r e a k the needed kind 4 qecificatiom. More partkular4, one &arb by determihg the w r level SRh4op - the operatiom provided in the nystem that one expecb to be explicitly invokable by a w r procem. Any restriction~on the permbsibiliQ of these operafhm can be factored out and d e part of the SecPoL Which codzuctom to add to ObjectPred and €‘“red dependr on the needs of the SRMops, dnce theae operations mast be able to elect Objectr and P”eain order to change (or, in our rppllutire replace) them. Particular Objectprrb and ProcesSPreds may .bo be needed by the M O L In dealing with there kind 2 qecE&m, decidonm are b c i made about ded kind 3 ~ p ~ i h t i In o d~e.h h g the SRMopa, it will become clear what the elemenb of mrt Arg, a krge Mion type containing d necoperator argumenb, ehould be. While a high-level description of the q d e m &ea mme information about the kinds of Procumca and Objectr that urist, the ObjeCtPredr and Procesapredr clearly demand that .bo certain Object and Proceaa O ~ & ~ O be M available. The additional detaib of Object and Procear repnsentationm and operatiom are dekrmlned by what the ruioas SR.Mopa mast do, and the needs of the W o l , the Interp, and the Scheduler. T h e componenb of the Hidory are princ i p e determined by the needs of the W o k in principle, the History can be ascd in detecting potential information flow and pmenthg it. The remljninl kind 2 mrb are the Scheduler and the Interp. The definition of the Scheduler may influence the internal structure of Requests. The definition of the Interp, which will tranalate w r level Requests into system Requeotd, will usunl4 lead to dditional, optem level SRMopa. We will trace the above proeees.througha &etch of how our template can be elaborated for

e,

MlNRc. We will take an example operatiom fork, kill, and interrupt. Fork h.S no argumenb, kill takes a ProcessId ugament, and interrupt .bo takes a ProcessId ugament. Fork requires that there be a way to create a new procem that inherib mme characteristics of the procees that issued the request to fork. Thus, Process needs to acquire an operation 124

mkchildProcex3B: Process x state + Procw (where the State argument is needed in computing an unwed ProcessId for the new procese). Kill and interrupt require that one be able to trace down all child Proceeses of a given Process; one of the simplest ways to specify this is to include a ProcessId component in any Process, referring to ib parent, and corresponding to a distinsaishing set operation parentproem: Process -+ Procedd. Since procesees are allowed to turn off interrupb, we add a flag interruptablePmxm: Process -e Boo1 to the distingnishing set. The file protection policy in MlNIX would be handled in the SecPoL Because access to a file by a proccm depends on a user name aaeociated with the process and the file, both Objecb, of which fiks are an example, and Processes,need associated aser names. Further detaib of the Process and Object epec%cations will become clear when one debthe appropriate SRMop to be issued by or deal with the various Procesees, e.g.: user Processes, 1/0 device procc%ees, the spakm process; and Objecb, e.g.: files, 1/0 bders, p'ipca, memory blocks, registers. We model the ieauing of an interrupt by the issuing of an interrupt Request which the. Scheduler will pick up immediately. Thus, Requ& need some kind of Priority component; Prioritq is a new kind 4 sort. We also sec that we need to d e h e a non-default Scheduler that can take priorities into account. We do not need any more than a trivial (onezlement) I-Ihtory for a rapid p r o t o m , since MINIX d a s not have a Wry mechanism. However, M indicated earlier, we might wbh to include one in order to ttat certain information 00w proper&. One obvioar me for a requeat interpreter (Interp)in a MINIX protois to translate 6k name h g a of R e q u d b e d by w r P " e a into absolute file ad-. Such a we of the Interp also i m p b lomething more about the representation of uacr Processes,namely that they Similar consideratiom ohow have a component that, in effeet, holda their working &tory. that part of the repmentation of a Procesr is an environment (which may be wed, for exampk, in interpreting operator names).

6. Handling other features of a prototype We will describe briefly here how we would expect our sptem to be able to handle a eampling of other operating q d e m featam that may or may not appear in MINX, and give an example ohowing that the decomposition in our template can be helpful in other wap. Multi-levelqueued for nquesb can be handled by an appropriate definition of a Priori@data type to be included Y a component of a Requeat. T h e maintenance of data =I& in a sptem can g e n e r w be modelled by including a &cLevel component in Objecb, and a User component in Pmceaws, where ekmenta of sort User have an rssociated &cLevel component; the notion of secLere1 can be Y complex M desind, and d o a not imply a linear order on eecurity kveb. Shared memory between p r o e m s can be managed with an A&& component in Objecb, and a Boo1 (boolean) component that would act Y a remaphore, and affect and be dected by operatioxu that Proccaeea would perform on Objecb (such an reading or writing to memory). The interpretation of a llbv operation into a eequence of sptem operations can be handled by interpreting a uacr Rcquat into a syntem Request whoa operator c a m a sequence of Requesta to be put in the RequeetLiut. At lome level, Requesb will be interpreted simp4 M themselves, and actidly affect the State in r a p other than adding new Requedq we will my that these are trividy interpreted. Increadqly ht-graiaed interpretation can be modelled by simply adding non-trivial translations of such Requesta to the Interp. It is not necessy to change any operator definitions, &ce these would no longer be ased directly. Of coarse, it would be necemuy to add new operator definitions for the new her-grained operations. 12s

6. Running a prototype Once a prototype has been defined in sufficient detail, it can be executed in the FASE (Find Algebra Specification and Execution) aptem [KJA83), in a manner which we will deecribe below. We will l h t ray a little about the FASE system. We find the llse of this v t e m convenient for several reaeons. Perhaps the most important reason is that specifications are executable whenever they do not involve quantXem. Even some specifications with quantifiers are executable, and the eyatem is able to identify a claw of such specifications which it guarantees it can execute (although, for efficiency EMOM, it beat to avoid quantXcation in a rapid prototlrpe, and in fact, in prsctice, we replace the Set specitlcations in our kmplate with Set implementations based on ordered lisb). There are, of course, other uyntema for executing qnxifications, ouch an O W [GMP83] and Affirm [GHM?8]. These madly involve algebraic (equational) epecifications. W e ouch specifications are sometimes straightforward to write, knowing when one has enough equations (or 00 many an to lead to incons;stency) can be a problem. By contrast, we find h d algebra specifications to be among the easiest specifications to write. One d a s not have the problem of proving d c i e n t compleknees and consisttncy of equations. Once one has determined the abstract representations M tuples of elemenb of varions oortd, the definitions of their associated operations are mually straightforward to derive from verbal descriptions. In addition, the FASE system is integrated with Lisp,80 that one can easily write Lbp p m grama to help build an initial configuration of the optem b e i i prototyped, an well M Lisp driven to exercise, aud hence test, one's specifications interactively. One can e a d y incorporate into a driver print routines that call operations from the rrpecification in order to display, for exampk, a mystem date repreeented in some convenient fashion by ita obeervable behavior. Specification m d tenting ue further much facilitated by a p d n for h o o t arbitrary unemMned syntax. With m appropriate grammar, one can easily handle the formation of eeta and oquencea, an well aa c a r c i o ~ and , avoid typing in lengthy (though posslaly, an in our exampk, descriptive) function names. U e r upnssiona are delimited in L i i by exclamation pinta, and in rpeci6catio~by underscores. Thm, in our MINIX example, we might nay at the L i s p lev& laser 0 calla uKill on 2 in MI to abbreviate (ne-

(*clnest

(-1 (appenWU

("erProcessId

c.w 0)

2) (nEUrgLW

o . ) )

M) (note that M in both the h e w be a Lisp variabk whose value ia of tort SRM). While ofcrc loading of operatom in the B ~ C & & ~ O M per ee in not dowed, it b feasibk to a great extent in the g r a m " , mince the pareer is abk to do typechecking of all but variables. We now bok at what we mean by executing the prototype. The top level SRM data type b provided with two operations, one that steps the State, and one that accepts a new Requat into the RequeatLbt. Under the rssnmption that all events in the system are nowimultaneow one can uae thae two O ~ ~ to O hand M simulate any equence of mntr in the optem. Of c o w , an initial c o d g u d o n of the ayutem har to be created by using the mlrsRM constractor in the SRM data type. Thia codguration &odd conform to any u p e c t d b ~ one haa about invarianta of the aptem; e.g., that no two Processes ahall have the m e Procadd. In addition, the eequence of menta mast be "kgd": for uampk, in MINIX, an interrupted Procam mast not h e any requd. The ueer of the prototype can either guarantee these thingo, or ebe tesb guaranteeing the invariants and the legalilq of requesta can be included in the q&m builder and driver. 126

7. Conclusions and future directions Our work to date has been concerned with creat‘hg a template operating Bystem specification and determining ita usabiity to captun the functional-level specXcationa of specific operating syetems. Besides treating a portion of MINM, we have specialired the template specification to capture the functional behavior of a aimple secure operating system. We believe that the operational nature of FASE specifications makes our methodology natural enough to be accessible to other system developers. We phn to nee our p r o t o w to vddate decisions relating to ~ d y management , of resources (e.g., error conditions), and fairness of mchedalers. To facilitate such teeting, we are developing a general driver to permit the @m to execute program scripta. We de0 plan to explore the u ~ l cof time stamps on reqnesb and expected execution timw to enable us to simulate performance dong with functional behavior. To support generd nee of our methodology, we would like to develop a interface that would make it easy to refine the sub-qccifications in a template while h y i n g within the restrictions corresponding to their “kinda”. Lastly, we hope to demonstrate the usefulness of the exeeutable template method in other as well, such as system architecture and hardware design.

8. References

I27