Formal Refinement for Operating System Kernels

342 Pages·2007·2.961 MB·English

by  Iain D. Craig MA, PhD (auth.)

Formal Refinement for Operating System Kernels
Iain D. Craig
Formal Refinement
for Operating System
Kernels
123
Iain Craig, M..A, PhD, FBCF, CITP
British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library
LibraryofCongressControlNumber: 2007931774
ISBN 978-1-84628-966-8 e-ISBN 978-1-84628-967-5
(cid:1)c Springer-Verlag(cid:2)London(cid:2)Limited(cid:2)2007
Apart from any fair dealing for the purposes of research or private study, or criticism or
review,aspermittedundertheCopyright,DesignsandPatentsAct1988,thispublication
may only be reproduced, stored or transmitted, in any form or by any means, with the
priorpermissioninwritingofthepublishers,orinthecaseofreprographicreproductionin
accordancewiththetermsoflicencesissuedbytheCopyrightLicensingAgency.Enquiries
concerningreproductionoutsidethosetermsshouldbesenttothepublishers.
The use of registered names, trademarks, etc. in this publication does not imply, even in
theabsenceofaspecificstatement,thatsuchnamesareexemptfromtherelevantlawsand
regulationsandthereforefreeforgeneraluse.
Thepublishermakesnorepresentation,expressorimplied,withregardtotheaccuracyof
theinformationcontainedinthisbookandcannotacceptanylegalresponsibilityorliability
foranyerrorsoromissionsthatmaybemade.
Printedonacid-freepaper.
987654321
springer.com
To my Father at 75
Preface
This book was written as a companion to my book on modelling operating
system kernels. It is intended to demonstrate that the formal derivation of
kernels is possible (and, actually, quite easy, or so I have found thus far).
Itisimportantforthereadertounderstandthattherefinementscontained
in this book are not the only ones I have performed of microkernels. To date,
I have refined four microkernels down to executable code and have now pro-
duced a kit of formally specified components that can be composed to form
kernels.Thefirstkernelincludedinthisbookisjustoneexampleofthiswork.
The second kernel, the Separation Kernel, is new and was partly constructed
out of the kit of parts (and the reader will see reuse in its specification and
refinement)andwasincludedforspecificreasonsthatwillbecomeclearanon.
Bothkernelstooklessthanthreemonths’workingtimetoproduce(theactual
time is rather hard to calculate because of frequent interruptions). Previous
experience in refining kernels also paid off in the sense that there was lit-
tle revision involved in their specification or refinement; the usual process of
yo-yoing between levels of the derivation was absent. This appears to be an
inevitable consequence of experience.
Thetimefactorhasbeenimportantintheproductionofthevariouskernels
that I have derived. The micro kernel helps in no little way by imposing the
rule that the kernel should be as small as possible. This is not to say that I
would not be interested or willing to refine a kernel such as the second one
I modelled in [4]. Such an exercise would be extremely interesting and one
I would very much like to undertake; however, it would require time (and I
am quite willing to put it in) and would require financial support. In today’s
climate,onewouldprobablyalsohavetoaskwhatthepointofsuchanexercise
would be.
It is necessary to position this book. Mainly, I believe it to be an essay
in formal methods software engineering and in operating systems. It can be
argued that this book is a contribution to refinement, in particular, to re-
finement in the large. There is nothing in the literature on the scale of the
refinements that are the subject of this book, as far as I am aware.
viii Preface
The Separation Kernel was included for specific reasons. First, there is at
leastonedocumentfromtheUSNationalSecurityAgency(NSA)recommend-
ing the Separation Kernel as the cryptographic kernel par excellence. In their
documents, the NSA also states that the formal specification of a Separation
Kernel would be highly desirable. Having looked at the various documents,
theoriginal paperby Rushby[11]inparticular, thestructureandfunctioning
of the Separation Kernel appeared to be fairly simple. This would appear to
have been one of the goals that Rushby had in mind when defining the archi-
tecture in the first place—it is another good example of how simplicity wins
every time (Less is more.) As a result, I wondered what a specification would
look like. What I found was what I expected. The result was quite easy to
specify and to refine.
Thereaderwillobservethatthereislittleornothingaboutbootstrapping
or hardware-specific initialisation. This is because we do not consider these
matterstobepartofthekernel;theybelongtotheenvironment withinwhich
the kernel executes.
Ithinkitnecessarytomakeacoupleofobservationsabouttherefinement
itself.IntheZliterature,twokindsofrefinementaredescribed:onerelational,
onefunctional.Therelationalrefinementistheworst-casescenario.Thefunc-
tional refinement is, in my experience, the usual case. Indeed, in more than
twenty years’ experience refining specifications, I have found that the rela-
tionship between the abstract and concrete statements is almost always an
identity. This experience is not restricted to kernels (of course) for a great
deal of the code I have produced during that time has had at least some for-
mally specified component (usually the components that are the hardest to
understand). The code has included virtual machines and parts of compilers,
so it is quite varied. For this reason, the fact that the abstraction relations in
this book are identities does not cause me any concern. (Steve Schumann re-
portsinaprivatecommunicationthesameexperience.)Idecidedthatproofs,
which are strictly unnecessary when using a functional abstraction relation,
should be included in the book. This was to show how they enter the refine-
mentprocessandtoshowthattheyarerelativelysimple(giventheprevalence
of identity relationships, proofs of similar complexity are to be expected and
thatisalevelofcomplexitythatcaneasilybehandled).Furthermore,Iwanted
to counter the claims that either the proofs could not be done or that they
weretoocomplicated;neitheristhecase.InthecaseoftheSeparationKernel,
a number of proofs are omitted (this was also for the reason that space was
getting short and devoting much more space to such a simple system did not
appear warranted). This is particularly the case with operations defined over
conjunctionsofstatespaces.Theproofsandpreconditionsofthecomponents
are given, as are the abstraction relations, so the production of the required
proofs is a straightforward matter and can be produced in a relatively short
period. In each case, the compound operation was checked against the com-
ponents and short (i.e., outline or sketch) proofs produced as a safety device.
Preface ix
The purely textual parts of this book were written using voice-input soft-
ware because my daily typing time was severely restricted on medical advice.
Usingvoice-inputsoftwareforthefirsttimewasaninterestingandsometimes
frustrating experience. The frustrations were mostly due to my being so used
to typing and I found that having to speak rather than compose on the key-
board sometimes confusingly difficult. In particular, initially, I found it quite
hard to navigate back and forth using just voice commands. (It led to the
occasional and unwanted inclusion of expletives in the text and I hope that
I have removed them all!) With greater experience, it turned out to be an
effective method for producing text. It is worth trying!
A Note on Interrupts
When I started out, it was conventional wisdom that interrupts should be
disabled for as short a period as possible. The reader will note that the space
betweendisablingandenablinginterruptsinthespecificationsandrefinements
that follow can be rather large. In some case (e.g., the interface routines at
the end of Chapter 3), the reason for this is that I wanted to emphasise the
fact that interrupts should be disabled for some part of the operation (for
reasons that will become clear in a second, without necessarily being forced
into saying which parts). Some processors have pipelines that might affect
the exact time at which the interrupt operation is performed; this cannot
be taken into account until the processor is known, so the safe option was
chosen. In addition, the period during which interrupts are disabled can be
extended when the desired response time of the system is known (here, we
have no such knowledge). In such a case, the interrupt operations can be
moved using the distributive law (p ∨ (q ∧ r) ⇔ (p ∧ q) ∨ (p ∧ r)) and the
idempotent laws (p ∧ p ⇔ p and p ∨ p ⇔ p). In the other cases, the change
to the interrupt flag (or whatever mechanism is used on the implementation
platform) might have some interaction with another part of the system (e.g.,
on the IA32, if the INT bit in the EFLAGS register is not the same value as
the processor interrupt flag, the system will crash); again, without knowing
the exact hardware, precise location of the interrupt operationsis impossible.
Acknowledgements
First of all, I would like to thank Beverley Ford for agreeing to publish this
book. Thanks are due in equal measure to Helen Desmond for making the
process of producing this book as painless as possible. They have jointly per-
formed the proof and copy editing stages of the test in order to expedite its
publication. I would like to thank Steve Schuman for reading the manuscript
while it was in sketch and in a more developed form and for a number of
extremely interesting discussions on the refinement process (any errors are,
naturally, my own fault). Considerable thanks are due to my brother, Adam.
Once again, he drew the figures for me; in addition, he patiently typed those
x Preface
parts from my dictation that could not easily be done using voice-input soft-
ware. Without his dedicated effort, the text of this book could not have been
completed.Asfortheotherswhohavehelped(theregulars),asalways,Ioffer
my thanks.
Iain Craig
North Warwickshire
April, 2007
Contents
1 Introduction............................................... 1
1.1 Reasons for Selecting the Examples ........................ 3
1.2 Refinement Method...................................... 7
1.3 Code Production ........................................ 9
1.4 Organisation of this Book ................................ 10
1.5 Relationship to Other Work .............................. 10
2 The Simple Kernel’s Organisation ......................... 11
3 A Simple Kernel........................................... 19
3.1 Types.................................................. 19
3.2 Hardware............................................... 23
3.3 The Process Table....................................... 28
3.3.1 Top Level ........................................ 28
3.3.2 Refinement One................................... 34
3.3.3 Refinement Two................................... 44
3.4 Process Queue .......................................... 56
3.4.1 Top Level ........................................ 56
3.4.2 Refinement One................................... 59
3.4.3 Refinement Two................................... 65
3.5 Priority Queue .......................................... 70
3.5.1 Top Level ........................................ 70
3.5.2 Refinement One................................... 78
3.5.3 Refinement Two................................... 91
3.6 The Scheduler ..........................................100
3.6.1 Top Level ........................................100
3.6.2 Refinement One...................................115
3.6.3 Refinement Two...................................118
3.7 Semaphores.............................................119
3.7.1 Top Level ........................................120
3.7.2 Refinement .......................................126
xii Contents
3.8 Semaphore Table ........................................126
3.8.1 Top Level ........................................126
3.8.2 Refinement One...................................130
3.8.3 Refinement One–Again.............................133
3.9 Synchronous Messages ...................................141
3.9.1 Preliminaries .....................................142
3.9.2 Top Level ........................................143
3.9.3 Refinement One...................................155
3.9.4 Refinement Two...................................158
3.10 The Clock ..............................................158
3.11 Sleepers ................................................161
3.11.1 Top Level ........................................163
3.11.2 Refinement One...................................170
3.11.3 Refiment Two.....................................180
3.12 User Interface...........................................188
3.12.1 System Initialisation ...............................188
3.12.2 Process Creation ..................................191
3.12.3 Process Management ..............................193
3.12.4 Inter-process Communication and Synchronisation.....198
3.12.5 Clock Operations and the Clock ISR.................201
3.12.6 Final Remarks ....................................202
4 The Separation Kernel.....................................203
4.1 Basic Architecture.......................................203
4.2 Extending the Architecture ...............................205
4.3 Summary...............................................206
4.4 An Overview of the Formal Specification ...................207
5 A Separation Kernel.......................................211
5.1 Basic Types ............................................211
5.2 Hardware Issues.........................................215
5.3 Security Exits and Return Values..........................218
5.4 The Process Table.......................................219
5.4.1 Top Level ........................................220
5.4.2 Refinement One...................................228
5.4.3 Refinement Two...................................237
5.5 Process Queues .........................................239
5.5.1 Top Level ........................................239
5.5.2 Refinement .......................................242
5.6 The Scheduler ..........................................242
5.7 Storage Pools ...........................................251
5.7.1 Top Level ........................................252
5.7.2 Refinement One...................................257
5.8 Raw Storage ............................................264
5.8.1 Top level .........................................264