La lecture en ligne est gratuite
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres
Télécharger Lire

Design of the SPEEDOS operating system kernel [Elektronische Ressource] / Klaus Espenlaub

De
292 pages
Universität UlmFakultät für InformatikAbteilung RechnerstrukturenDesign of theSPEEDOSOperating System KernelDissertation zurErlangung des Doktorgrades Dr. rer. nat.der Fakultät für Informatikder Universität Ulmvorgelegt vonKlaus Espenlaubaus Biberach a.d. Riß2005Official Copy, serial number df13c6b7 d6ed e3f4 58b6 8662375a2688Amtierender Dekan: Prof. Dr. Helmuth PartschGutachter: Prof. Dr. J. Leslie Keedy (Universität Ulm) Prof. Dr. Jörg Kaiser (Otto von Guericke Universität, Magdeburg)Gutachter: Prof. John Rosenberg (Deakin University, Geelong, Victoria, Australia)Prüfungstermin: 11.07.2005iiiAbstract(Eine inhaltsgleiche, deutsche Fassung dieser Übersicht ist ab Seite 243 zu finden.)The design of current operating systems and their kernels shows deficiencies in re specttothestructuringapproachandtheflexibilityoftheirprotectionsystems. Theoperatingsystemsandapplicationssufferunderthislackofextensibilityandflexib ility. Theprotectionmodelimplementedinmanyoperatingsystemsisnotpowerfulenough to represent arbitrary protection conditions on a more fine grained granu laritythangivingreadand/orwriteaccesstoanentireobject. Additionallycurrentoperating systems are not capable of controlling the flow of information betweensoftware units effectively. Confinement conditions cannot be expressed explicitlyand thus confinement problems can only be solved indirectly.
Voir plus Voir moins

FakultätUniversitätfürInformatikUlm

Abteilung

Design

echnerstrukturenR

of

Operating

Erlangung

the

SPEEDOSSystem

zurDissertation

desDoktorgrades

ernelK

.Dr

.rer

InformatikfürakultätFder

UlmUniversitätder

vonvorgelegt

EspenlaubKlaus

aus

a.d.Biberach

2005

Riß

nat.

Official

,Copy

Amtierender

serial

number

Dekan:

.ProfGutachter:

.ProfGutachter:

.ProfGutachter:

Prüfungstermin:

Prof.

df13c6b7-d6ed-e3f4-58b6-8662375a2688

.Dr

Helmuth

artschP

Dr.J.LeslieKeedy(Universität

Ulm)

.Dr(Otto-von-Guericke-Universität,KaiserJörg

osenbergRJohn

11.07.2005

(Deakin

,University

Geelong,

Magdeburg)

ictoria,V

Australia)

Abstract

iii

(Eineinhaltsgleiche,deutscheFassungdieserÜbersichtistabSeite243zufinden.)
Thespecttodesigntheofstructuringcurrentoperatingapproachandsystemstheandflexibilitytheirofkernelstheirshowsprotectiondeficienciessystems.inThere-
ility.operatingThesystemsprotectionandmodelapplicationsimplementedsufferinundermanythisoperatinglackofsystemsextensibilityisnotandpowerfulflexib-
larityenoughthantogivingrepresentreadarbitraryand/orwriteprotectionaccesstocondiantionsentireonaobject.moreAdditionallyfine-grainedcurrentgranu-
operatingsystemsarenotcapableofcontrollingtheflowofinformationbetween
softwareunitseffectively.Confinementconditionscannotbeexpressedexplicitly
andFurtherthusconfinementcomplicationsproblemswiththecanonlyprotectionbesolvedsystemandindirectly.especiallythesoftware
causedstructurebyinthemodernuseofopetheratingout-ofsystems-processbasedmodel.onIttheisextremelymicrokerneldifficultapproachtospe-are
cifyaccessrightsappropriately,becausetheclient/serverparadigmdoesnoteasily
allowmissionsaoftherelationshipserver.toFbeocusingestablishedonclient/serverbetweenthestructuresroleofthefavoursclientaandsingle,thecentralper-
serverimplementation.Specifyingasoftwaredesignandcommunicationmodel
forapplicationsattheoperatingsystemlevelimpairstheirstructure.
areInthereactionabstractiontothisofactivityobservation,andareSPEEDOSorthogonalfollowstothethein-processinformation-hidingmodel.Processesobjects.
Thismodelispartofthedesignofmanyobject-orientedprogramminglanguages
andafewoperatingsystems.Themethodcalldoesnotswitchprocesses,ittrans-
fersvalenttoexecutionthetoout-ofanother-processobjectmodel,inabutthecontrolledin-processfashion.modelThismodelprovidesisalmostadvantages,equi-
becausetheprocessidentifiercorrelatestoasubject.Howeverthisonlyhelpswith
protection,butdoesnotmagicallyimprovetheprotectionsystem.
satilityTheoftwoaccessmajorrightdeficienciesspecificationidentifiedandtheandstructuringaddressedofinthethisthesisoperatingarethesystemver-in
balancingconjunctionthewithdutiestheandapplications.powersofThethekernelSPEEDOSanddesigntheplacesapplications,theinemphasisorderonto
obtainaflexibleandextensibleoverallsystem.
invocations.SPEEDOSThesesupportschecksfreelyareprogrammableimplementedwithprotectionbracketchecksmethods,forindividualwhichinterceptmethod
othermethodinvocations.Theconceptwasinventedinthecontextofcomponent-
tureorientedbeyondtheprogrammingstateofthelanguages,artinwhichobject-orientedaremeanttoprogrammingimprovethelanguages.softwareInstruc-the

iv

operatingsystemcontextthisisanewconceptwhichallowstheimplementation
ofprotectionchecksandsimilarcodeinuser-levelcode.Bracketmethodsmaye.g.
denyaccesstothetargetmethodbasedonarbitraryrulesormayimplementaccess
monitoring.Inotheroperatingsystemsitisnotpossibletoimplementthesecases
code.user-levelwithcompletelyBracketsmayalsoserveasabasisforimplementingconfinement,bycheckingthe
clientandtargetmoduleidentityandtheinformationthatispassedbetweenthe
modules.InSPEEDOSthereisafurthermechanismwhichallowsconfinementrules
tobeenforced.Thisadditionalmechanism,whichcanbeexpressedthroughbitsin
themodulecapabilityusedtoinvokethetargetmodule,complementsthebracket-
basedconfinement.Bothmechanismshavedifferentstrengthsandweaknesses.
AnotherimportantaspectoftheSPEEDOSdesignisthedelegationofmanyoper-
atingsystemdutiestoindividualapplicationsoftwaremodules.Thedesignofthe
kernelexplicitlyrestrictsthedutiesofthekerneltosecurity-relatedbasicmechan-
isms.Allpolicydecisionsaremadeinuser-levelmodules.Thedelegationofoper-
atingsystemdutiestotheindividualapplicationmodulesisonlysensibleforduties
whichcanexploitapplicationknowledgeanddonotneedglobalknowledge.Cer-
tainresourcemanagementdutiesneedtobeimplementedincentralisedmodules,
otherwisetheallocationefficiencywouldsuffer.Makingdecisionsasdecentralised
aspossibleavoidsmanystructuralproblemsofmicrokernels,whichalsoattempt
todelegatefunctionalitytouser-levelservers,butresultsinacompletelydifferent
andlessflexibleandextensibleoperatingsystemandapplicationstructure.
Thekernelimplementsonlypolicy-neutralmechanismsanddelegatesallpolicy
decisionstouser-levelcode,inordertominimisethesizeofthekernel.Asanin-
tentionalside-effectthismaximisestheflexibilityandextensibilityoftheuser-level
modules.Effectivelythecompleteoperatingsystemcharacteristicsaredetermined
byuser-levelcode.Theresultisanoperatingsystemkernelthatimplementsonlya
fewmechanismsintheformofkernelinstructionsthatenhancethebaseprocessor
instructionset.Mostsuchkernelinstructionsdealwithaspectsrelatedtoprotec-
tion.TheSPEEDOSkernelimplementsthein-processmodel,whichavoidsmany
protectionproblems,becauseprocessesrepresentusers,notservices.Theortho-
gonaldesignofmodulesandprocessesisthekeytoaflexible,freelyprogrammable
protectionsystem,basedoncapabilitiesandbracketmethods.
Intheprototypeimplementationitisshownthatthevirtualmemorymodelused
todescribethemodulestructurecanbemappedefficientlytothecurrentpage-
basedmemoryarchitectureimplementedbythestandardprocessorarchitectures
availabletoday.Itisnotnecessarytodesignacustomprocessorarchitecture,al-
thoughcertainimprovementsinthevirtualmemoryimplementationprovidedby
theprocessorhardwarewouldbedesirable.Thisobservationconfirmstheexperi-
encesmadebythedesignersofothersingle-address-spaceoperatingsystems.
Thedesigndescriptioninthisthesisreflectstheexperiencesmadeduringthe
implementationoftheprototype.Theprototypehelpedidentifyingsmallerrors
andinconsistenciesinthedesign,howeverthechangescouldnotbeincorporated
intheprototypeduetotimeconstraints.

Contents

1

2

Introduction1.1Motivation.................................
1.2AimsofSPEEDOS.............................
1.3OverviewoftheThesis..........................

OperatingSystemConceptsandApplicationIssues
2.1WhatIsanOperatingSystem?......................
2.1.1TheOperatingSystemasaResourceManager.........
2.1.2TheOperatingSystemasaVirtualMachine..........
2.2MemoryModel..............................
2.2.1MemoryHierarchy........................
2.2.2Non-VirtualMemoryOrganisation...............
2.2.3GeneralVirtualMemoryOrganisation.............
2.2.4VirtualMemoryasExtendedComputationalMemory.....
2.2.5DirectAddressability.......................
2.2.6Segmentation...........................
2.2.7Paging...............................
2.2.8CombinedSegmentationandPaging..............
2.3ProcessModel...............................
2.3.1Out-of-ProcessModel......................
2.3.2In-ProcessModel.........................
2.3.3EvaluationoftheProcessModels................
2.3.4PersistentProcesses.......................
2.3.5AddressSpaces..........................
2.3.6Multithreading..........................
2.3.7Interrupts.............................
2.4DeviceDriversandFileSystems.....................
2.4.1DeviceDriverFunctionality...................
2.4.2DeviceDriverInterface......................
2.4.3FileSystemFunctionality....................
2.4.4FileSystemInterface.......................
2.5ResourceManagement..........................
2.5.1CPUScheduling..........................
2.5.2I/OScheduling..........................

v

1133

556678910111213151718192020212122232424252626272829

vi

3

2.6

2.7

2.8

2.9

Contents

2.5.3PhysicalMemoryScheduling..................
2.5.4VirtualMemoryScheduling...................
2.5.5EnergyManagement.......................
Communication..............................
2.6.1Addressing............................
2.6.2Synchronisation.........................
2.6.3Buffering.............................
2.6.4Explicitness............................
SecurityModel..............................
2.7.1Protection.............................
2.7.2Lampson’sAccessMatrixModel.................
2.7.2.1AccessControlLists..................
2.7.2.2CapabilityLists.....................
2.7.3AccessRuleModel........................
2.7.4AccessControl..........................
2.7.4.1DiscretionaryAccessControl.............
2.7.4.2MandatoryAccessControl...............
2.7.5AccessRights...........................
2.7.5.1DirectAccessRights..................
2.7.5.2SemanticAccessRights................
2.7.5.3GenericAccessRights.................
2.7.5.4Metarights.......................
2.7.6ImplementingaSecurityModel.................
2.7.7Confinement...........................
2.7.8CovertChannels.........................
2.7.9Trust................................
2.7.10Authentication..........................
Structuring................................
2.8.1LayeredSystems.........................
2.8.2Abstraction............................
2.8.3Client-ServerSystemStructure.................
2.8.4Module-BasedSystemStructure.................
2.8.5OperatingSystem–KernelBoundary..............
2.8.6GraphicalUserInterfaces....................
2.8.7CodeLibraries..........................
Summary.................................

SurveyofMechanismsinExistingOperatingSystemDesigns
3.1UNIX....................................
3.1.1HistoryandStructure......................
3.1.2MemoryandProcessManagement...............
3.1.3ResourceManagement......................
3.1.4FileSystemandDeviceDrivers.................
3.1.5ProtectionMechanisms......................

293030303132333435353637383939404041414143434344444546464749495050525354

55555657575858

Contents

3.2

3.3

3.4

3.5

3.6

3.7

3.1.6Authentication..........................
3.1.7CommunicationandSynchronisation..............
3.1.8CriticalDiscussionandSummary................
KeyKOS..................................
3.2.1Structure.............................
3.2.2MemoryandProcessManagement...............
3.2.3ProtectionMechanism......................
3.2.4Communication..........................
3.2.5CriticalDiscussionandSummary................
MONADS.................................
3.3.1AimsoftheMONADSProject..................
3.3.2Structure.............................
3.3.3MemoryManagement......................
3.3.4ProcessManagement.......................
3.3.5ProtectionMechanisms......................
3.3.6CommunicationandSynchronisation..............
3.3.7AuthenticationandAccounting.................
3.3.8UserInterface...........................
3.3.9CriticalDiscussionandSummary................
Amoeba..................................
3.4.1MemoryManagement......................
3.4.2ProcessManagement.......................
3.4.3Structure.............................
3.4.4Communication..........................
3.4.5ProtectionMechanisms......................
3.4.6CriticalDiscussionandSummary................
MonashPasswordCapabilitySystem..................
3.5.1Structure.............................
3.5.2MemoryandProcessManagement...............
3.5.3ProtectionMechanism......................
3.5.4Confinement...........................
3.5.5ResourceManagement......................
3.5.6CriticalDiscussionandSummary................
Mach....................................
3.6.1ProblemsIdentifiedinPreviousOperatingSystems......
3.6.2MemoryManagement......................
3.6.3ProcessManagement.......................
3.6.4Communication..........................
3.6.5ProtectionMechanisms......................
3.6.6Structure.............................
3.6.7CriticalDiscussionandSummary................
L4.....................................
3.7.1AimsofL4.............................
3.7.2Structure.............................

vii

5959606262636465666767676870707172737475757676787879818181828484858687888889909192939394

viii

4

Contents

3.7.3MemoryandProcessManagement...............94
3.7.4ProtectionMechanismsandCommunication..........95
3.7.5CriticalDiscussionandSummary................96
3.8Grasshopper................................96
3.8.1AimsofGrasshopper.......................96
3.8.2Structure.............................97
3.8.3MemoryandProcessManagement...............97
3.8.4ProtectionMechanism......................99
3.8.5Synchronisation.........................100
3.8.6CriticalDiscussionandSummary................100
3.9Mungi...................................101
3.9.1AimsofMungi..........................101
3.9.2MemoryandProcessManagement...............101
3.9.3Structure.............................102
3.9.4ProtectionMechanismsandCommunication..........103
3.9.5Authentication..........................105
3.9.6ImplementationProperties....................106
3.9.7CriticalDiscussionandSummary................107
3.10Exokernel.................................108
3.10.1Structure.............................108
3.10.2ProtectionMechanisms......................109
3.10.3PersistentStore..........................110
3.10.4Synchronisation.........................111
3.10.5CriticalDiscussionandSummary................111
3.11FlukewithFlask.............................112
3.11.1Structure.............................113
3.11.2ProcessandMemoryManagement...............114
3.11.3ProtectionMechanisms......................115
3.11.4DeviceDriversandFileSystems.................117
3.11.5CriticalDiscussionandSummary................117
3.12ConcludingRemarks...........................118
3.12.1Summary.............................118
3.12.2Implications............................119

121ObjectsBracketingforModel4.1BracketingasaLanguageConcept...................122
4.1.1BasicBracketingConcept....................122
4.1.2BracketDefinitionExample...................123
4.1.3BracketUsageExample.....................124
4.1.4Call-OutBrackets.........................126
4.1.5RelationshipbetweenQualifiersandTargets..........128
4.1.6BracketSequencing.......................129
4.1.7QualifierswiththeirOwnInstanceMethods..........129
4.1.8RelatedProgrammingLanguageConcepts...........130

Contents

5

6

ix

4.2ImprovingSecuritywithBrackets....................131
4.2.1ExamplesofUsesofBracketing.................131
4.2.2SecurityviaBracketing......................131
4.2.3ConfiningFlowofInformationwithBrackets.........132
4.2.4SPEEDOSBasicSecurityPhilosophy...............133
4.2.5Compiler-BasedSecurity.....................133
4.3ImplementingBracketsinOperatingSystems.............134
4.3.1Prerequisites...........................135
4.3.2ProtectionofParameterListsandReturnValues........135
4.3.3ManagingBracketLists.....................136
4.3.4SimilarOperatingSystemConcepts...............137
4.4Summary.................................138

139ModulesCompositeforModel5.1AimsbehindMinimalKernels......................140
5.1.1RelationshipbetweenSizeandComplexity...........140
5.1.2DistinctionbetweenMechanismandPolicy...........141
5.1.3PrerequisitesforaPolicy-NeutralKernel............142
5.2NewOperatingSystemStructuringApproach.............142
5.2.1Co-ModuleStructure.......................143
5.2.2CompositeModuleStructure..................144
5.2.3Co-ModuleManagement.....................145
5.2.4InvocationofCo-Modules....................145
5.2.5White-BoxCo-ModuleFunctionality..............146
5.2.6Co-ModuleUsebytheKernel..................147
5.2.7BracketingCo-Modules.....................147
5.3DelegatingFunctionalitytoModules..................148
5.4RelatedConcepts.............................149
5.4.1Microkernels...........................149
5.4.2Exokernels............................149
5.5Summary.................................150

DesignoftheSPEEDOSKernel153
6.1DesignPhilosophy............................153
6.2RoleoftheKernel.............................155
6.2.1KernelPersistence........................155
6.2.2KernelInstructions........................156
6.2.3UseofModuleInterfacesandDataStructures.........156
6.3ModuleCapabilitiesandObjectTypes..................157
6.4PersistentVirtualMemory........................158
6.4.1Containers............................158
6.4.2Paging...............................159
6.4.3Segmentation...........................160
6.4.4SegmentCapabilitiesandPointers...............161

x

7

Contents

6.5CompositeModules............................163
6.6ProcessandInterruptManagement...................165
6.6.1ApplicationThreads.......................165
6.6.2StackOrganisationandParameterPassing...........167
6.6.3ControllingExecutionofIndividualThreads..........168
6.6.4ThreadScheduling........................169
6.6.5ImplementingKernelInstructions................170
6.6.6InterruptHandling........................171
6.6.7Synchronisation.........................172
6.7CodeandLibraryModules........................173
6.8ProtectionMechanisms..........................176
6.8.1ModuleCapabilities.......................176
6.8.1.1Metarights.......................178
6.8.1.2CopyingModuleCapabilities.............179
6.8.1.3CreatingModuleCapabilities.............180
6.8.1.4Inter-ModuleCallandReturn.............180
6.8.1.5LibraryCall.......................181
6.8.2IntegratingBracketMethodsintotheKernelDesign......182
6.8.3TheThreadSecurityRegister..................183
6.8.3.1ConfinementRights..................184
6.8.3.2EnvironmentRights..................186
6.9DeviceDrivers...............................187
6.10BootstrappingandClosingDowntheSystem..............188
6.11Summary.................................189

SignificantEffectsoftheSPEEDOSKernelDesignonanOS191
7.1UniformPersistentDistributedVirtualMemory............191
7.1.1ContainerDirectoryModules..................192
7.1.2PageTableManager.......................194
7.1.3MemoryAllocationwithinaContainer.............194
7.1.4MigratingContainers.......................195
7.1.5StabilityofthePersistentStore.................196
7.1.6ReplicationofModulesinaDistributedSystem........196
7.2ManagingProcesses...........................198
7.2.1ControllingThreadExecution..................198
7.2.2SchedulingThreads.......................199
7.2.3RelationshipbetweenProcessesandUsers...........200
7.2.4ImplementingUser-LevelSynchronisationProtocols......201
7.2.5Inter-ProcessCommunication..................202
7.2.6DistributedThreadManagement................203
7.3ManagingContainersandtheirContents................204
7.3.1TheCo-ModuleManager.....................204
7.3.2TheCodeManager........................206
7.3.3Linkers..............................207

Contents

xi

7.3.4TheThreadManager.......................209
7.3.5ManagingQualifierLists.....................209
7.3.6ImplementationIssuesinBracketMethods...........210
7.3.7DescribingtheModuleInterface.................211
7.4GlobalIssues...............................212
7.4.1ProtectionandSecurity.....................212
7.4.2ControllingCompositeResourceUsage.............213
7.5ConcludingRemarks...........................214

8PrototypeforIntelx86Architecture217
8.1FundamentalImplementationDecisions................217
8.2VirtualMemoryImplementation.....................218
8.2.1SegmentationinaPagedVirtualMemoryArchitecture....219
8.2.2ImplementingaHugePagedVirtualMemory.........221
8.3SchedulerandSynchronisation.....................222
8.4ImplementationofKernelInstructions.................223
8.5ModuleCallImplementation.......................224
8.6Summary.................................227

229Conclusion99.1Summary.................................229
9.2NewContributions............................231
9.3FutureResearchDirections........................232
9.3.1ImprovingtheProcessorArchitectures.............232
9.3.2FurtherModuleStructuringPossibilities............233
9.3.3HeterogeneousSystems.....................233
9.3.4UserInterfacesforPersistentSystems..............234
9.3.5Implementationon64bitProcessorArchitectures.......234

AKernelInstructionReference235
A.1EnvironmentalQueries..........................235
A.2ThreadSecurityRegister.........................236
A.3ManagingSegmentCapabilities.....................237
A.4ManagingModuleCapabilities......................238
A.5MethodInvocationandReturn.....................238
A.6ThreadManagement...........................239
A.7Synchronisation..............................240
A.8VirtualMemoryManagement......................241
A.9DeviceDriverSupport..........................241

Zusammenfassung

Bibliography

243

245

xii

Contents

FiguresofList

xiii

2.1Translatingbetweenvirtualaddressandphysicaladdress.......10
2.2Traditionalbreakdownofcomputationalandpersistentstorage...12
2.3Segmenttableentryforpuresegmentation...............14
2.4Addresstranslationwithsegmentedvirtualmemory..........14
2.5Addresstranslationwithpagedvirtualmemory............16
2.6Pagetableentryforpurepaging.....................16
2.7Virtualaddressfororthogonalsegmentationandpaging.......17
2.8Segmenttableentryfororthogonalsegmentationandpaging....18
2.9Intermediateaddressfororthogonalsegmentationandpaging....18
2.10Pagetableentryfororthogonalsegmentationandpaging.......18
2.11Accessmatrix,describingtheaccessrightsofasubjecttoanobject.36
2.12Semanticaccessrightsexample:bankaccountsinterfaces......42
2.13Layeredvirtualmachinedesign.....................47

3.1RPCcapabilityfieldsinAmoeba.....................79
3.2CapabilityrepresentationintheMonashPasswordCapabilitySystem82
3.3CatalogueentryintheMonashPasswordCapabilitySystem.....82
3.4CapabilitystructureinGrasshopper...................99
3.5Mungipasswordcapability........................103
3.6Mungiprotectiondomainextensioncall................104
3.7TheFlasksecurityarchitecture.....................116

4.1Anormalmethodinvocation.......................122
4.2Activatingabracketmethodassociatedwithatargetmethod.....122
4.3Augmentingatargetmethodwithabracketmethod.........123
4.4Typedefinitionforreader/writersynchronisation...........124
4.5Possibleimplementationofreader/writersynchronisation......125
4.6Usingbracketstosynchroniseanobjectinstance............125
4.7Targetobjectwithbothcall-inandcall-outbrackets..........126
4.8TypedefinitionforasubsetofHoare’smonitorsynchronisation...127
4.9Implementationforreleasablemutualexclusion............127
4.10Bracketsequencingofcall-outandcall-inbrackets..........129
4.11TypedefinitionforaqualifierforACLprotection............130
4.12TypedeclarationofaBell-LaPadulaqualifyingtype..........132

xiv

FiguresofList

5.1Conceptualstructureofaninformation-hidingmodule........143
5.2Structureofacompositemoduleconsistingofseveralco-modules..144
5.3CompositemodulecontentincludingCo-moduleManager......145
5.4Possiblecontentofacapabilitytoaco-module.............145
5.5Severalco-moduleswithaccesstocommonprivatedata.......146
5.6Compositemodulecontentincludingbracketsupport.........147

6.1Simplifiedstructureofamodulecapability...............157
6.2Logicalstructureofthepagedvirtualmemoryaddress........159
6.3Structureofasegregatedsegment...................160
6.4Representationofasegmentcapability.................162
6.5Simplifieddatastructuresdescribingasingleco-module.......164
6.6Co-moduleTabledescribingthecontentofacompositemodule...164
6.7ThreadTableandthreadrepresentationwithinaprocess.......166
6.8Linkagestackwithparameterandreturnvaluesegments.......167
6.9CodeTablerepresentationwithinacodemodule...........174
6.10Representationofamodulecapability.................176

7.17.27.3

8.18.28.3

ContainerDirectorystructuremanagingtwodiscs...........192
Dynamicallylinkedprogram(semi-staticlinking)...........207
Moduleusingarbitrary,dynamicallylinkedlibraries..........208

Translationofaprocessor-supportedvirtualaddresstoaSPVA....220
DeterminingthemainmemoryaddressandconstructingaTLBentry221
Partialpseudocodeimplementationforcall_opinstruction.....225

List

2.12.22.32.42.5

ablesTof

Typicalsizeofavailablestorageinacomputersystem...
Internalinterruptsources,relatedtoinstructionexecution
Externalinterruptsources,relatedtohardwaredevices..
Classificationofcommunicationsystemproperties.....
Semanticaccessrightsexampleforbankaccounts.....

.....

.....

.....

.....

.....

.....

xv

823233142

xvi

List

of

ablesT

1Chapter

Introduction

1

.uselesslynothingdoesNature(Aristotle,384–322BC)

notModernadequatelyoperatingseparatesystemsandconsistprotectofathecomplicatedindividualsoftwaresubsystems,structuresuchaswhichmemorydoes
management,processmanagement,persistentfilestoreandinter-processcommu-
nication.Theresultisthatcontroloverboththecomplexityoftheoperatingsystem
andthesecurityofapplicationsoftwareislost.
Thepreviousparagraphseeminglyreferredtoprotectionandsecurityindiscrim-
scope.inately.SecurityHoweverisatherenotionisaforasetdistinctionofmatchingbetweentheseprotectiontermsdefinitions,thatrelateswhiletopro-the
tectionSecurityistheisdefinedmechanisminthethatintroductioncontrolsaccesstothetoanEuropeanindividualITSECpieceofguidelinesinformation.[74]as
ofcombinationtheconfidentiality:preventionoftheunauthoriseddisclosureofinformation;
integrity:preventionoftheunauthorisedmodificationofinformation;
availability:preventionoftheunauthorisedwithholdingofinformationor
resources.Thisdefinitionisnotdirectlyrealisableinthecontextofanoperatingsystem
notiondesign,asprotectionsecurityplaysrequiresamoreanumberimportantofrolematchinginthedesignprotectionofandecisions.operatingThussystem.the
Inthisthesisnewmodelsforrepresentingprotectioninthestructureofanop-
eratingsoftwarearesystemandpresented.forThesestructuringmodelsbotharetheusedtooperatingdesignsystemanewandtheoperatingapplicationsystem
kerneland,basedonthekernel,anoutlineofanoperatingsystemarchitecture.

Motivation1.1

intheComparedoperatingtothesystemsituationareainthetoday1970shasanddecreased1980sthedrasticallynumber.Isofthisresearchanindicationprojects
thatallimportantproblemsaresolved?

2

Introduction1Chapter

Inmyopinionthisisnotthecase.Thecurrentstateoftheartincommercially
availableoperatingsystemisbasedmainlyonthemicrokernelarchitecturede-
velopedinthe1980s,whichimprovedthestructureofanoperatingsystemimple-
mentationsomewhat,butdidnotaddresstheproblemsassociatedwithsecurity,
complexity,flexibilityandextensibility.Insteadtheaimislimitedtoreachingap-
proximatelythesecurityandfunctionalitylevelofsystemsdevelopedinthe1970s,
suchasUNIX.Thisargumentappliestoallpopularoperatingsystems,sinceallof
themhaveseveresecurityproblemsthatareimplicitlypartoftheirstructure.
Whileresearchoperatingsystemsdonotsharethisresistancetofundamental
changes,theyfocustodaytoanalarmingextentonsolvingtheefficiencyproblems
introducedwiththemicrokernelarchitecture.Thisobsessiononperformancewas
justifiedwhenprocessorswereslowandexpensive,buttodaythebiggestchallenge
istodesignsystemsthataresecure.Proofofthefailureofthecurrentoperating
systemswithrespecttosecuritycanbetakenfromthenews,whichreportsmore
andmorefrequentlyonsecuritybreaches,viruses,worms,fraudulentrepresenta-
tionsinelectronicmailmessagesandsoon.
Theprovokingarticle“NoSilverBullet—EssenceandAccidentinSoftwareEn-
gineering”[35]byFredBrooksurgesustoreconsiderthecurrentworkinsoftware
engineeringintheAristoteliantermsessenceandaccident.Inthispaperhedescribes
fouressentialdifficultiesthatanysoftwareengineeringprojecthastoface:
Complexity:Constructingasoftwaresystemisinherentlycomplex,becauseno
twopartsaresimilar.Thedesignofsoftwarediffersfundamentallyfromthe
designofaconcreteobjectinthatitisnotbuiltusingseveralidentical,stand-
ardisedpartsascomponents.Softwaresystemshaveahugenumberofstates
thatallneedtoworkcorrectly.
Conformity:Softwaresystemshavetoconformtotheconventionsdefinedbyhu-
mans.Theconventionsareoftenbotharbitraryandconstantlychanging,e.g.
becauseofadjustmentsinthelegalsystem.Thislimitsthedesignspaceofthe
softwaredesignerandintrinsicallymakesthesoftwaremorecomplicated.
Changeability:Softwareiseasilychangeableandthuschangingitisperceived
asasimpletask,asthealternativewouldbetochangetheothersystemsto
whichthesoftwaresystemmustconform.Additionallysoftwareoftenisused
foramuchlongertimethanthedesignershaveanticipated.Thisrequires
thatthesoftwaredoesnotprecludechangeinitsenvironment.
Invisibility:Itisnotpossibletovisualisesoftware.Whilecertainaspectsofsoft-
warecanbevisualised,softwarehasnoinherentorobviousrelationshipto
space.Thishinderscommunicationamongthedesignersandimplementors
system.softwareaofThisfundamentalcriticismistakenintoaccountinthisthesis,andplaysakey
roleintheanalysisofthecurrentstateoftheartinoperatingsystemdesign,which

SPEEDOSofAims1.2

3

ativelyappearsinstaticchaptersoftware3.Assystemsweshallthatseeforceinapthisotentiallyanalysis,opinadequateeratingsystemsstructureareontherel-
softwareApplicationsystemssoftwarewhicharedesignerswrittenareforsothem.usedtotheconstraintsthattheyrarely
tems,perceivebutthemthisatdoesall.notleadOperatitongsimplersystemsareapplications.themselvesSobothcomplicatedpartsofasystemsoftwarehavesys-
betweenundesirabletheoperatingproperties.systemThisandthesisattemptsapplications.toTheredefineaimisthetosimplifyseparationbothofdutiessides.
Atsystemthewillsamebetimereplacedthebystatic,uniform,arbitraryflexiblestructureandandextensiblefunctionalitysoftwareofunitsthethatoperatingelim-
theinatethesemanticdistinctiongapbetweenbetweenboththepartsofoperatingacompletesystemandsoftwareitssystem.applications,narrowing
TheSPEEDOSacronymindicatestheintendedcorefunctionalityandthetarget
Thisstructure:emphasisesSecurePthatrotectedthisEthesisxecutiondoesEnotaimnvironmentforaforsingleDidealistributedsystemObjectSdesign,ystems.but
thattheresultsshouldbegenerallyapplicableforawidevarietyofsystems.

ofAims1.2

SPEEDOSTheaimofthisthesisistopresentanewarchitecturaldesignforanoperatingsys-
tem,consistingofasmall,flexiblekernelandasetofuser-levelmoduleswhich
characteriseonepossiblestyleofoperatingsystem.Thefocusisontheroleofthe
kernelanditsfunctionality,andthecharacteristicsoftheactualoperatingsystem
maybeindependentlychosenbythedesigneroftheoperatingsystem,inaccord-
ancewiththerequirementsofapplicationsoftware.
Protection,flexibilityandextensibilityaretakenintoaccountatthelowestpos-
siblelevel,theoperatingsystemkernel.Whilethisdoesnotdirectlycorrelateto
thecomplexityofthesystem,itactuallyremovesmanycomplexitiesthataretoday
partofoperatingsystems.Selectinguniform,orthogonalandpowerfulabstractions
isthekeytoaclearerandmoresecureoverallsystemdesign.

ThesistheofOverview1.3

art,Thisathesisdescriptionconsistsofinnewessencesoftwareofthreesystemparts:modelsananalysisthatofsolvethestructuringcurrentstateofproblemsthe
ofTheoperatinganalyticalsystems,partanddescribesadescriptionfundamentalofakerneloperatingandsystemoperatingconceptssystemanddesign.exist-
ingincorporatedoperatingintosystemallandoperatingkernelsystems.designs.AChapterselection2ofdiscusseseleventheimportant,conceptstypicallyunusual
andinfluentialoperatingsystemsandtheirprinciplesaresummarisedandevalu-
ofatedwhichinarechapterstill3.inThisuse,surveyandmoreincludesbothexperimentalconventionalresearchoperatingoperatingsystems,systemssomethat

4

Introduction1Chapter

focusonspecialaspectsofoperatingsystemdesign.Theevaluationrevealsthatall
theoperatingsystemsanalysedhavestructuraldeficiencies,whichmaketheoverall
systemmorecomplicatedthannecessary.Inmostcasesthehighsystemcomplexity
isalsoaccompaniedbyalackofprotection,flexibilityandextensibility.
Thesecondmajorthemeofthethesisproposesanimprovedmodelforstructur-
ingsoftware,auniformsoftwarestructureforrelativelylargeobjectswithastrictly
enforcedsemanticalinterface.Thismodelhastwoparts.
Thefirstpartisconcernedwitheliminatingthelimitationsintheprotectionsys-
temsoftheanalysedoperatingsystemsbyintroducingqualifyingobjects,asde-
scribedindetailinchapter4.Qualifyingobjectschangethebehaviourofthequal-
ifiedtargetobjectwithwhichtheyareassociatedbyinterceptingmethodcalls.
Qualifyingobjectsareseparatelyprotectedobjectswhichmayimplementarbitrary
accesschecksorsupplementtheprotectionsystembyimplementingaccessmon-
itoring.Anyfunctionalmodificationthatcanbeexpressedbyaddingaprelude
and/orpostludetoacalltothetargetobjectorbymakingtheinvocationofthe
targetobjectsubjecttoanarbitrarilydefinedconditioncanbeimplemented.
Thesecondpartoftheproposedimprovedsoftwarestructuringmodel,discussed
inchapter5,comprisesamechanismtorepresentcompositeobjects,consistingof
severalindependentlyprotectedsub-objects.Thissoftwarestructureisthebasis
forthedelegationofmostoperatingsystemandkernelfunctionalitytoindividual
objects.Theimprovedprotectionmodelalsoappliestotheoperatingsystem.
Thethirdmajorthemeofthethesisisdescribedinchapters6and7.Inthese
chaptersanewkerneldesignandimportantaspectsoftheenvisagedoperating
systemarchitecturearedescribed,basedontheproposedsoftwarestructuringcon-
cepts.Inchapter6theemphasisisplacedonthekernel,providingthemechanisms
neededtoimplementasecuresystem,comprisedofboththeoperatingsystemand
theapplications.ThemajoreffectsoftheSPEEDOSkerneldesignontheoperating
systemarchitecturearepresentedinchapter7andillustratethatthestructuralim-
provementsworkasexpected.Thenewsoftwarestructuresareappliedtoselected
operatingsystemelementsinordertoassesstheirpotential.
TheseparationofpolicyandmechanismusedthroughouttheSPEEDOSdesign
allowstheconstructionofaveryflexibleandextensibleoperatingsystemkernel
thatisasuitablebasisforimplementingahighlysecuresystem.
ImportantaspectsoftheprototypeimplementationofthekernelontheIntelPen-
tiumarchitecturearediscussedinchapter8.Implementingasecureoperatingsys-
temonaconventionalprocessorarchitectureposesspecialdifficultiesandrequires
makingcompromisestoachieveanefficientimplementation.Themostimportant
resultisthatthekernelmaybeimplementedwithanacceptableefficiencywithout
sacrificingthefundamentaldesign.Thusitispossibletoimplementahighlysecure
operatingsystemforacheapoff-the-shelfprocessor.Theimplementationstrategy
iscompatiblewithmostcurrentlyavailableprocessorarchitectures.
Intheconclusion,chapter9,theresultsofthethesisaresummarisedandpossible
outlined.aredirectionsresearchfutureFinallyasummaryofthekernelinterfacespecificationappearsinappendixA.

2Chapter

OperatingApplicationSystemIssuesConceptsand

5

Mostdecisions.propertiesTheofdifferentanoperatingchoicesandsystemtheemergeresultingfromonlypropertiesafewhaveimportantbeenstudieddesign
fewthoroughlydecisionssinceandthelateoccasionally1950s.tryingThearesearchtotallywasdifferentdrivenapproach.generallyThebylargechangingnum-a
berespeciallyofchoicessincemakesthereitareimpossiblenumeroustosystematicallyinterdependencies.analysetheindividualaspects,
Certaincombinationshavebeensomewhatneglectedastheydidnotfitwellin
thearestilldesignsvaluableofpopularideasin(boththe“generesearchpool”andthatarecommercial)worthlookingoperatingat,systems.especiallyifThereone
departssuccessfulfromoperatingthewell-troddensystems,whichpathshavefollowedtheirbyrootstheinfewthe1980sremainingandearlycommercially1990s.
ThischapteranalysesthecurrentlyestablisheddesignspacefrombothanOS-
centredandanapplication-centredviewpoint.Ithinkthatputtingemphasisjust
ontheapplicationsOSorandapplicationtheOScanproducesonlybesuboptimalreducedsystems.effectivelyTheifasemanticcompatiblegapbetweendesign
philosophyapplicationsisfromused.dealingAnwithoperatingthesystemcomplexityisaofactualmeanstohardwareanend,namelyimplementations.tofree

2.1WhatIsanOperatingSystem?

muchTheremisonorethanuniversallyincasesofagreedotherlargedefinitionofsoftwarewhat(e.g.anOScompilers,is,anddatabasedefinitionssystems).differ
Silberschatz[261]statesinhisbookonoperatingsystemsquiteaptly:

“Ingeneral,however,thereisnocompletelyadequatedefinitionofan
operatingsystem.Operatingsystemsexistbecausetheyareareason-
ableThewayfundamentaltosolvegoaltheofproblemcomputerofcreatingsystemsaistousableexecutecomputinguserprogramssystem.
andtomakesolvinguserproblemseasier.[...]
Thereisalsonouniversallyaccepteddefinitionofwhatispartofthe
operatingsystemandwhatisnot.”(p.5)

6Chapter2OperatingSystemConceptsandApplicationIssues

Whyisthis?Computersareappliedtoallsortsofproblemstoday,andhave
vastlydifferingprocessing,memoryandperipheralresources.Thedutiesandre-
sponsibilitiesofanOSforamicrocontrollerandforamainframecomputerinitially
seemtohavenothingincommon.ObviouslyanOSsuitableformicrocontroller
usewithatmostafewkilobytesofcodeandamainframeOSwithseveralhundred
megabytesofprogramscannothavethesamefunctionality.
Yettherearetwocommonfeatures.AnOSprovidesanabstractmachinethat
iseasiertousethantherawhardware.OntheotherhandanOSmanagesthe
resourcesavailableinthesystem,makingthemavailableappropriatelytotheap-
programs.plication

2.1.1TheOperatingSystemasaResourceManager
One(physicalaspectandofanvirtualOSisones)thatitsuchasmanagesCPUtime,resources.memoryAcomputerspace,discsystemspacehasandresourcesvarious
exclusiveperipheraluse,devices.someinProgramsshareduseneedtoabespecificexecuted.setofresources,someofthemin
TheOSmanagestheserequestsandallocatestheresourcestospecificprograms.
ThisAllocationsisperformedmaybewithaconflicting,certainsoptheolicy,OSe.g.mustpriority-based,decidewhichmaximisingprogramscanefficiencyrun.
fairness.or1andTheefficienttwoinmostitsownimportantresourcepropertiesconsumption.ofanOSAarevariationthatitoftheshouldberesourceeasytomanageruse
viewpointisthenotionofacontrolprogram.TheOScontrolstheexecutionof
applicationprogramstopreventerrorsandmisuseofthecomputer.

2.1.2TheOperatingSystemasaVirtualMachine
Anactualimplementationofacomputersystemtypicallyhasanarchitecture(in-
task,structionbutisset,farmemorytoocomplexorganisation,fortheaverageperipherals)thatprogrammerperformstodealwellforwith.aWecertainno
minglongerofprogramperipheralindevicemachineregisterslanguage,forandmosttrytoapplications.stayawayThefromOSisdirectacollectionprogram-
ofhardware-dependentpiecesofcodethathasa(mostly)hardware-independent,
pendseasy-to-useonmanyinterface.systemThelevelcharacteristics,ofabstractionincludingthatthecanandprocessorshouldspeedbeandprovidedmemoryde-
size.OneAfteraspectall,ofthevirtualprovidingmachinesabstracthaveinterfacestobeto“run”theonrealhardwareishardware.theopportunity
betousedmakeonvastlyapplicationsdifferingcomputers,hardware-independent.withTdifferentodaymanyprocessorsoftwarearchitecturespackagesandcan
peripherals.TheapplicationsusestandardisedservicesprovidedbytheOS.
1ingTheuserdependinginthisonthecontextpisurposebothofthetheendcomputeruserandsystem.theapplicationprogrammer,withvaryingweight-

ModelMemory2.2

7

Designingthesehardware-independentOSinterfacesisnotaneasytask.Itin-
volvesforesightdecidingwouldbewhichrequireddetailstoaremakerelevanttherightandwhichdecisionsareinannot.environmentSometimesthatperfectis
.quicklymoreeverchangingThevirtualmachineaspectofanOSiscloselyrelatedtoitsstructure,andthe
layeredapproachthatisinherentwiththevirtualmachineideaisjustoneofthe
inmanymoredetailpossibilities.insectionOperating2.8.systemandapplicationstructureswillbediscussed
ApplicationsoftwarereusethroughportingtoadifferentOSistypicallyacom-
plexanismsjob.andTheinterfaces,differentwhichoperatinghavesystemstobeprovidereflectedslightlyinthetototallyapplications.differentThismech-ac-
cidentalcomplexitycanbedecreasedwithcarefulsoftwareengineering,making
portabilitydevelopmentofthecostcansoftwarebeashareddesignbyagoal.largerThenumberrewardofisthatcustomers.theoverallapplication

ModelMemory2.2

Probablythemostresearchefforthasbeenspentonexploringhowtoorganise
theresearchmemoryseemstoavailablebetofutilethefromOStheandcurrentapplications.assumptionAconsiderable“memoryisamountcheap”.ofPthater-
andsonalevencomputersmallsystemsportablewithdeviceshundredslikeofcellularmegabytesphonesofhaveRAMseveralaremegabytescommonplace,of
maingenerallymemory.affordable.HarddiscLargercapacitiescomputerinexcessinstallationsof100useahgigabytesostofaredrivesthetonormachieveand
Waggregateithallthiscapacitiesmemorywhichcapacitycanbe2–3availableordersatofcomparablymagnitudelowlarger.prices,application
2Suchprogrammersnonchalanceandusersisascarcelyluxurythinkprovidedaboutbythemodernmemoryoperatingusageofsystems.theirTheprograms.cost
isalibraries.sophisticatedSurprisinglymemoryeverythingmanagementstillworks,butimplementedthepriceinofithardware,ishigh,theOSespeciallyand
thenumberoftransistorsintheCPUhasmushroomedduetothelargecaches
haverequiredmadetocumbersomeaccommodateandtoday’sbloatedapplications.modernsoftwareTheadvancessystemsinpossible.microelectronics
Thriftymemoryusagemeansalittlemoreeffortintheindividualprograms(and
it.Itsometimesunleashesbetterthetrueeducationpowerofofprogrammersmodernisallprocessors,thatiswhichneeded),sufferbutmoreiswellandworthmore
fromthelimitedbandwidthformainmemoryaccessesoutsidethecurrentlycached
locations.memoryofset2files.TStrangelywentyyeaenoughrsofmanywidespreadprogramsforavailabilityUNIXorofMicrosoftvirtualWmemoryindowswerestillusenotenoughadditionaltobreaktemporarythe
“tohabitofreducemanymemoryprogrammersusage”.Ttohiscriseatesomewhatintermediatesurprisingfilesincerepresentationsitisusuallyofthenotbulktrivialdatatoprocesscreateeda
linearisedversionoftheinternalrepresentationofthedata.

8Chapter2OperatingSystemConceptsandApplicationIssues
intheThefirstfastplace,decreasinghowevercostinperthetransistorcurrentmadesituationmanyimprovingsystemsintheTablestructure2.1ofpossiblesoft-
waresystemshasfarmorepotentialtoenhanceapplicationefficiency.
AtlasSystemY1962earMain96memoryKBPersistent576KBmemorydrumVM6sizeMB
IBMS/360-671966512KB8MBdrum16MB
ICLBurroughs2900B6700196919751.51MBMB120200MBMBdiscdiscno4limitGB
Cray-1197632MBn/an/a
IBMPC/XT1984128KB10MBdiscn/a
SunSPARCstation119894MB200MBdisc4GB
DECAlpha199232MB500MBdisc8TB
SunAppleUltraP1owerMac61001995199412816MBMB5004MBGBdiscdisc164GBPB
IBMRS/600044P2000256MB9GBdisc16PB
ApplePowerG52003256MB80GBdisc16PB
standardstandard64PCbitPC200420041024512MBMB200160GBGBdiscdisc2564TBGB
Table2.1:Typicalsizeofavailablestorageinacomputersystem
Todayweprocesslargeramountsofdata,butresourcefulprogramdesignwill
makeprogramsrunfasterevenwithlimitedresources.Operatingsystemkernels
areusage.aboutKernelstheonlyshouldsoftwareuseaslittlecategoryvirtualwhichismemoryoptimisedaddress[43]fortranslationminimumcacheresourceentries
possible.aslinescacheandHierarchyMemory2.2.1Everycurrentcomputersystemimplementsseveraldifferentclassesofmemory,
arewiththevastlyregisters.differingTheirspeedcapacityandissizeverylimited,characteristics.usuallyThearoundfastest32memorywords.Ravailableegisters
holdtemporaryvaluesduringprogramexecutiontoavoidfrequentmemoryac-
cesses.reductions,Thenowaccess(2004)timeisreachingtypically0.3ans,singleclockcorrespondingcycle,toaavalueclockthatratehasof3seenGHz.vast
Mainmemory(alsocalledphysicalmemory)isreasonablyfast,withaccesstimes
intheorderof10–100cyclesandahighcapacityintheorderofseveralmegabytes
toseveralhundredmegabytes.Technologyimprovementsweremostlyspenton
memoryincreasingclockcapacityrate,isandeverthereforeincreasing.thegapThebetweenprohibitiveprocessorcostofclockanrateaccessandtomainmain
memorytriggeredtheinventionofmemorycaches.Cachesreducethefrequency
ofmainmemoryaccessesintypicalapplicationsbytwoordersofmagnitude.

ModelMemory2.2

9

Amemorycacheis(accessa(mostly)timesinthetransparentorderofpartial1–10copycycles).oftheThemaincachememorymemoryiscontentfasterin,butfast
alsolevelsmoreofcacheexpensivememoryperbit.withModernvaryingspeedsprocessorandsizesimplementationstooptimiseoftenthehavecacheseveralmiss
rateincluded(whichonistheusuallyprocessorlesschipthanto2%).avoidTypicallytime-consumingoneortwooffof-chipthefastestaccesses.cachesare
Theaddressessimplestandvalues.modelforSincecachesoperatingisansystemsassociativehavememorylittle,controlholdingoverpairsofcaches,memorythis
here.sufficeshallmodelIttransistorsshouldandnotbethereforeforgottentothethatchipcachessizeofcontributecurrentprocessorsignificantlytotheimplementations.numberAnof
extremeapproximatelyexample93%isoftheallInteltransistorsItaniumare2usedprocessortoimplement(codenamecachesandMadison),only7%whereto
implementtheactualprocessingunit(30milliontransistorsfortheCPUonachip
withtakingupoverallspace410withoutmillionfurthertransistorscosts3).Inwouldafewbeyearsacceptable,thiscouldbutbecachethe(beingnorm.Justvery
fastmemory)alsocontributestotheoverallpowerconsumption.

OrganisationMemoryVirtualNon-2.2.2Assoonasprocessorsbecamefastenoughtobeshared4,therewasapressingneed
toallocatememorytodifferentrunningprograms.Initiallythiswasdonestatically
toavoidtherun-timecostofmemoryallocation.Itsoonturnedouttobeaproblem
toeffectivelydeterminetheamountofmemoryusagestatically.
Dynamicmemoryallocationseemstobeasolution,butitcreatesjustanother
problem:thefreespacebecomesfragmentedifoneallowsarbitraryallocations
theandmaindeallocations.memory.OnlyThereawouldcontiguousbeblockenoughcanfreebespace,usedbybutaitisprogram.scatteredallCompactingover
yetmemoryverybyfewcopyingsystemsblocksactuallyofusedallocatedthisapproach.memorytoThebepracticaladjacentproblemscouldsolve(pointersthis,
betweenAnotherallissueallocatedthatisblockshardtohavesolvetoisbetochanged)separatemadedifferentittoousers’expensive.processaddress
inspacesoneprogrameffectively.canIfcauseprocessesanotherpotentiallyprogramtomodifycrasheachother’unexpectedlys.memory,thenerrors
2100A,TherethewerelimitseveralregistersolutionsintheICTimplemented1900orthe(suchasprotectionthefencekeyregisterapproachintheinHPthe
IBMmemory.S/360),Thiswhichprovidedwereamorehoweverpowerfulsoonmodelsupersededcapablebyaofnewsolvingconceptcalledprotectionvirtualand
allocationissuesinasinglestep.
3MainstreamNumberstakenEnterprisefromthePlatformsInteloftheDistinguishedFuture”,byLectureDileep2003“BillionBhandarkarT,ransistorOctober2003,ProcessoravailableChipsatin
4http://www.he.educationinindia.net/DistinguishedLecture2003.pdf.
thefullWhethercapacitytheofprimarytheaimprocessorwasistoreduceirrelevant.thecostofoperatingacomputersystemonlyortouse

10Chapter2OperatingSystemConceptsandApplicationIssues

OrganisationMemoryVirtualGeneral2.2.3Vtobeirtualexecutedmemorythat(seearealsolarger[56])thanhasthebeenphysicalintroducedmemoryto.Thisallow(arelievedsetof)theprogramsapplica-
tionprogrammersfromdealingwithdisruptivemechanismssuchasoverlays[214]
orsplittingprogramsalongfunctionalboundariesintoseveralphases5.Virtual
memorymadeallthesemechanismsobsoleteandallowedtheprogrammerstofo-
cusThisonthepositiveapplicationeffectblendsprogram,todaynotwithonthehowtofitthoughtlessitintoandmemorywasteful.attitudemen-
tionedaboveandcreatesanexplodingneedforphysicalmemory.Thecachesneed
togrowevenfaster,tomakeupfortheincreasinggapbetweenprocessorandmain
memoryclockrate.AlsotheTLB(thevirtualmemoryaddresstranslationcache)
becomesabottleneckiftheworkingsetofprogramsbecomestoolarge,resulting
inperformancelossduetothrashingeffects.
159]ThefirstconstructedimplementationbytheofUniversityvirtualofmemoryManchesterwasinwiththeFAerranti.tlassystemThe[158,system113,was
operationalin1963andwasapredecessorofmainframecomputers.
Interestinglytheyenvisagedasinglelevelstoremechanism6fromthebeginning,
anideathatsincehasbeenalmostforgotten(notableexceptionstothisaree.g.
entMULTICvirtualS[212]memoryandwillbeMONADSdiscussed[238]).inThemoreconceptdetailinofsectiondirectly2.2.5.addressablepersist-
Conceptuallyvirtualmemoryintroducesanadditionalstepinmemoryaddress-
ing,addressnamely(seetheFiguretranslation2.1).Sincefromtheavirtualrelationmemorybetweenaddressvirtualtomemoryaphysicaladdressesmemoryand
physicalmemoryaddressesispartial,thetranslationmayfail.

virtualaddressaddresstranslationorphysicaladdress
mechanisminterrupt

Figure2.1:Translatingbetweenvirtualaddressandphysicaladdress

Failedattemptstotranslatevirtualaddressestophysicaladdressescauseanin-
terrupt.ThisisusuallyhandledbytheOStoimplementdemandpaging(and
toterminateprogramsthattrytoaccessnonexistentpartsofthevirtualmemory
space).Differentstrategiestoloadanddiscardpartsofthevirtualmemoryhave
beendevised(e.g.in[24]),andtodaymostsystemsimplementavariantofthe
5ThisdesignisstillpresentinmanyCcompilers,areminiscenceoftimeswhenacompletecompiler
did6notfitintophysicalmemory.
mentedThedrumwithfilestoragesystemsusedforthatmobackingstthecurrentvirtualsystemsmemoryprovide.wasAnottlastheonlytruemadepersithestentcomparablystoragesmalimple-l
drumstorageavailable,butnotpaperormagnetictapes,whichheldthebulkofpersistentdatain
systemsconstructionofthatatime.sequentialDrumaccessstoragemediumwasandtoothereforeexpensivenotforbulksuitablestorforage,backingwhilevirtualtapestoragememoryis.by

ModelMemory2.2

11

“leastvirtualrecentlymemoryused”presentstrategyinthe,whichphysicalselectsmemorytheasleastarerecentlyplacementusedcandidate.portionofThisthe
dostrategynotdirectlyrequiresasupportlittleit,workbuttotheimplementperformancewithbenefittheiscurrentusuallyprocessorsmuchhighersincetheythan
thecost.SpendingafewCPUcyclestoavoidthousandsofidlecycleswaitingfora
discaccessisusuallyagoodtradeoff.
Thefundamentalbasisforimplementingvirtualmemoryefficientlyistheobser-
vationthatmostofthememoryusedbyaprogramisusedrepeatedlyforsometime
(temporallocality)andthatprogramsusuallyprocessseveraldataitemsstoredin
closememory,itproximityexhibits(spatialthesamelocality).propertiesIftheasmainothermemorypartsofistheusedasmemoryacachehierarchyfor.virtualThe
mainmemoryhastobelargeenoughtoholdacertainpartofthevirtualmemory,
calledtheworkingset[55],toavoidthrashing.
Therehasbeenresearchonprogramoptimisationsforefficientvirtualmemory
usage[45,102,82],minimisingtheworkingsetbyreorderingcodeanddatato
largemaximiseamountslocalityof.Duephysicaltothememoryefficientavailablevirtualinmemorycurrentcomputerimplementationssystemsandthistheis
analmostforgottenpartofthestateoftheart.OnlyOSkernelsarecurrently
manuallyoptimisedtoobtaintheleastworkingsetpossibletoreducethepenalty
duetodisplacedcacheandTLBentries.Theideaof(semi-)automaticoptimisation
oflocalitypropertieshasbeenusedfromtimetotime,butwasneverincorporated
intotheaveragecompiler.Thisissueisconsideredimportantenoughonlyinthe
contextofhigh-performancecomputing,wherecleveruseofvirtualmemorycan
greatlyimprovetheutilisationofthecachesandmainmemory.

2.2.4VirtualMemoryasExtendedComputationalMemory
Vtionalirtualmemorymemory,waswhichusuallylosesitsregardedcontentafterexclusivelyasystemasanshutdown.extensionItoftheneedsacomputa-cheap
andreasonablyfastdirect-accessmediumasabackingstoreforcurrentlyunused
partsreplacedofbythevirtualmagneticdiscmemory.storageInitiallywhenthisitswasperformancemagnetichaddrumbeenstorage,improvedbuttowasac-
thanceptabledrums,levels.andDiscswerewerethereforeasubstantiallyveryattractivecheaper(bothreplacement.generallyTodayandperdrumkilobyte)storage
isaforgottentechnologyjustascorememoryorbubblememory.
Soeventuallyboththepersistentdataandvirtualmemorywerestoredonthe
samemedium.Mostoperatingsystemsmadenoattempttounifybothmemor-
iesnotcopelogicallyeven,sincewiththethevirtualamountofmemorypersistentmanagementdatastoredhardwareonaandsinglesoftwarediscandcouldex-
tendingthevirtualmemoryspaceaddscomplexitytotheOS.BythetimeVLSI
implementationsofprocessorarchitecturesbecamecommonplace,thisstatusquo
wastemporarysofamiliarfileswouldthatmostmaketheirsoftwarejobdeveloperssubstantiallynevereasier.realisedthatgettingridof

12Chapter2OperatingSystemConceptsandApplicationIssues

Toimplementvirtualmemory,acertainportionofthediscwassetasidetostore
thevirtualmemorycontent(seeFigure2.2).Thismeantthatallcurrentlyrunning
programsduplicationareofstoredmemorytwice:contentonceinbetweenthefilevirtualsystemandmemoryonceandinfilevirtualstorememoryis.typical,This
sinceatleastprogramsarepartofbothworlds.Originallytheywereloadedinto
forcedmemorymostwithoftheregularnewfilevirtualoperations.memorySometimescontenttheimmediatelyshortagebackoftophysicaldisc.memory

memorymain

storagecomputational

memorymaintoextension

storefile

storagepersistentFigure2.2:Traditionalbreakdownofcomputationalandpersistentstorage
Manyoperatingsystems(e.g.UNIX)havesinceintroducedmemorymappedfiles,
thewhichduplicationessentiallyofisaprogramstripped-downfiles,butisversionnotasofflexibledirectlyorversatileaddressableasfiles.MULTICThisScuredfiles.

AddressabilityDirect2.2.5Intheprevioussectiontheseparationofvirtualmemoryandfilestorageplayed
animportantrole.Todatemostprocessorarchitectureshavetroublesupporting
avirtualmemorythatcanholdalldatastoredonpersistentmedia,commonly
calledpersistentvirtualmemory(therearealsopersistentprogramminglanguages,
whichhavetheiroriginsinthekeypaperonorthogonalpersistence[17]).Discs
havesupportgrown4togigabyteshundredsofofvirtualgigabytesmemoryinsize,space.yetmostObviouslyprocessorthisisnotarchitecturesenoughforonlya
largerreal-worldbymappingsystem,onlyhoweveractivethesegmentsvirtualintomemorythevirtualspacecanmemorybeoftheconceptuallyprocessormuch.
ilityMUL[26,TICS50],[212]butitwasalsothecontributedforerunnertoofthesystemsgeneralthatbeliefprovidedthatthisdirectapproachaddressab-is
tooexpensivetobeusedinareal-worldsystem.Theinitialimplementationwas
notTheveryGeneralefficient,ElectricandGE645althoughprocessorthishasitranbeenondidremediednotlatersupport,thetheprejudicelargenumberstuck.

ModelMemory2.2

13

ofsegmentsthatwouldhavebeenneededtorepresenteveryfile.Thereforethe
rightsprogramswerehadtochecked)selectandwhichbasedfilesontheythiswantedinformationtoaccessthe(atsegmentthispointtablesthewereaccessset
up.Programsgenerallyneedaccesstoveryfewfilesatatime.
Othersystemsadoptedthisidea,ande.g.intheMONADSsystemitwascom-
systemplementedthatwithcan(atrepresentthatalltime)itsahugepersistentvirtualstoreasaddress,virtual60bitsmemorywide,(seeresulting[2]).inPro-a
grammersnolongerhavetoworryaboutthetransformationoftheinternaldata
structurestoapersistentrepresentation(beitfilesordatabases).
allowingTheideapagewasfaultslatertobegeneralisedresolvedtofromencompassremotediscsdistributed(DSM).systemsThisneeds[137,afew174],bitsby
inthevirtualaddresstoidentifythenode,andcreatesaprogrammer-friendlyway
tocommunicateinadistributedsystemwithoutexplicitnetworkprogramming.
ImplementingDSMisnotassimpleasitseemsatfirst.Inreallifesystemsit
istodealcommonwiththatcrashedobjectsdiscschange(seetheir[139]).locationtoSynchronisation,optimisesystemconsistencyandperformancestabilityor
becomeboundaries.majorProvidingissues.anacceptableSynchronisationmemorycannoteasilyconsistencybemodelenhancedtotoapplicationscrossnodeis
alsodisturbingnottrivial.theItothermustnodesbe(aspossiblelongtoasshuttheydowndonotanodeneeddandatarestartfromitthislater,node),withoutand
unexpectedcrashesorfailedlinksshouldnottakedownthewholesystem.
Determiningastrategyforcreatingsnapshotsofthevirtualmemoryforrecovery
ofpurposestheinitial(commonlyworkinthecalledMONADSstability)isprojectstillseeunder[106,research125].The[16].useForofanalgorithmsoverview
involvedborrowedinfromtransactions)databaseseemssystemspromising,(suchasasthecreatingproblemsdependencyarecloselygraphsrelated.ofpages

Segmentation2.2.6Intheearlycomputersystems(aftermultiprogrammingbecamestandardbutbe-
toforedividevirtualitupmemoryintovariablebecamesizeblockscommonplace)asarequestedpopularbywaythetomanageapplications.memorywas
theWithsegmentsuchaschemeboundaries)thatprogrammingresultinerrorsaccessescanbetomdetectedemory(ifthelocationshardwareoutsidechecksthe
boundsofasegment.Itsimplifiesthelinkingofprograms(alsocalledbindingin
Onlysomethesystems)tableofsinceallsegmentsreferencesneedstoareberelativeconstructedtothestartwhenoftheaprogramparticularissegment.loaded,
ifreflectingsegmentstheareactualclassifiedmemoryintocode,layoutofconstantstheandprogram.writableProtectiondata.isThehardwarestraightforwardcan
unitseasilyofchecktheforsoftwareerrors,andareimprovingthereforesystemthenaturalresilience.basisforSegmentsprotectionrepresentmechanisms.logical
Inmodification,suchaandsegmentedlikewisememoryexecutionmodelofcodeconstantscanbecanberestrictedprotectedtoareasfromthatunwantedactually

14Chapter2OperatingSystemConceptsandApplicationIssues

containcode.Anditprovidesabasisforimplementingvirtualmemory:justan
extraunset)presentcausesbitantoainterruptsegmentfortableaccessesentrytothe(seesegment.Figure2.3)TheisOSneeded,handleswhichthisby(if
loadingthesegmentoffthedisc(potentiallydisplacingothersegments).

AddressLengthState:present/changedAccessRights:e.g.read/write/exec

Figure2.3:Segmenttableentryforpuresegmentation
Asegmenttableentrycontainstheinformationtocalculatethemainmemory
addressofeveryword(orbyte)withinasegment,plusstatusinformationand
accessrights.Inavirtualmemorycontext,thestatusbitsindicateifthesegmentis
presentornot,orifithasbeenchangedsinceitwasloaded.Totranslatebetween
avirtualaddress(consistingofthesegmentnumberandtheoffset)andaphysical
address,anaddresstranslationunit(ATU)asshowninFigure2.4isneeded.
addressvirtualmemorymainSW

tablesegment012...S...n

SsegmentW

Figure2.4:Addresstranslationwithsegmentedvirtualmemory
isAallocatedsevereanddrawbackreleasedofmanagingrepeatedlymemoryoverinthelifetimevariable-sizedofthechunkssystem,isthatcreatingmemoryex-
isternalnoguaranteefragmentationthata(asitreleasedoccurssegmentoutsideisthedirectlyallocatedadjacentmemorytoaareas).currentlySincefreeblockthere
ofmemory,thememoryavailablebecomesmoreandmorefragmentedovertime.
block)Theamountdependsofonthefragmentationpolicyused(andtoalsoselectthetherun-timecandidatecostfreeofblockfindingfromthewhichcandidatethe

ModelMemory2.2

15

domblocktobeallocationallocatedsizes,isbuttakenunfortunatelyfrom.Knuththe[160]real-lifesimulatedallocationthepatternsbehaviour[23]withviolateran-
thisassumption.Usuallythereareveryfewsmallallocations,ahugenumberofre-
lativelysmallallocations(intheorderof30–200bytes),andfewlargeallocations
(see[309]),whichmeansthatafterawhilealmostallfreeblocksareverysmall.
Along-runningprograminasystemwithasimplesegmentallocationstrategycan
aendupsegmentwithafromhugethefreenumberlistisoftinyalwaysputsegmentsbackinintoitsfreethelistfreeiflist.the“leftover”partof
costlyAsitandhascanbeenthemselvesmentionedincausesectionmore2.2.2,problemsattemptsthanattheymemorysolve.Inthecompactioncontextare
ofvirtualmemorythebiggestissuesareI/Ooperationsduetovirtualmemory
management.Asegmentmustnotbemovedinphysicalmemoryaslongasthe
atdiscdanger.controllerSincecouldI/Omakeoperationsdirectareslowmemory,thisaccessespotentiallytoit,orcausesthelongsystemdelays.integrityis
WiththeadventofRISCprocessors,segmentationbecamealmostextinct.The
AOSTUiscode,alittlebutthatmorecertainlycomplexdoesthannotforpagingwarrant(seescrappingnextthesection)idea.anditrequiresmore
Thetruecauseismorelikelythebaddesignofthe“last”CISCprocessorsin
thesupport1980s.forAeverygoodbuzzwordexamplethatwaswastheIntelpopularatiAPX432thattime[213].It(capabilities,includedmultipro-hardware
cessing,executionspeedobject-orientationwasinadequate.andtheIntelhigh-levelhastilylanguagedevelopedAda),amorebutfailedconservativeroyally.pro-The
cessorhistory,,thee.g.Intelin200480286,theredeliveredwasnotina1982.singleThereferenceiAPX432toitfiascoinhasthebeenIntelwebwipedpagesfrom
(earliertherehadbeenareferencetoitfromthecompanyhistorypages).
Asaresult,thebabywasthrownoutwiththebathwater,andeverythingresem-
blingaCISCideawasbanned.TheexistingCISCarchitecturessurvivedbecause
ofthesoftwareMotorola68000compatibility.architectureTheIntelisx86oftenusedarchitectureinembeddeddominatessystems.thePCAllmarkettrulynewand
designsfromthemid-1980shavebeenRISCprocessors,withoutsegmentation.

agingP2.2.7Managementofthevirtualmemorybasedonvariable-sizedblocksisnottheonly
feasibleoption,infactthefirstvirtualmemoryimplementation(seesection2.2.3)
usedapage-basedapproach.Usingafixed-sizeblock(apageofmemory)asthe
unitagementofandtransfereliminatesbetweenvirtualexternalmemoryfragmentation,andphysicalbutcannotmemoryreflectsimplifieslogicalthestruc-man-
turesaseasilyassegmentation.Allocationbasedonfixed-sizeblocksissubjectto
internalfragmentation,whichmeansthatusuallymorespacethanactuallyneeded
isallocatedinordertoreachablockboundary.Ifpageaccessrightsaretheonly
optiontoimplementnon-overwritablecodeandread-onlyconstants,thisforces
puttingdifferentlogicalcontentinseparatepages,increasingfragmentation.

16Chapter2OperatingSystemConceptsandApplicationIssues

ImplementingtheATUforpaging(seeFigure2.5)issimplerthanforsegmenta-
tion,becausethephysicaladdresscomputationisjustconcatenationinsteadofan
addition,andpagingrequiresnolimitcheckaswithsegmentation.
addressvirtualmemorymainPW

tablepage012...PFP...n

PFframepageW

Figure2.5:Addresstranslationwithpagedvirtualmemory
onThetheearlyprocessor,butimplementationsthatsoonofpagedbecamevirtualimpossiblememorybecauseimplementedthepagethetablepagebecametable
toolarge.CurrentRISCprocessorsusuallyimplementatranslationlookasidebuffer
and(capabletheofrestisholdingkeptainfewatabledozenintomemoryaround100(dependingfrequentlyontheusedpageimplementation,tableentries),the
ispagetypicallytablepartcouldofitselfthebeprocesspaged,state,i.e.soparteachoftheprocessvirtualhasitsmemory).“own”Thevirtualpagememorytable,
fairlyisolatinghighthemanagementprocessesfromoverhead.eachIfothera.sharedSharingpageofispagestoisbepossible,displacedbutfromincursmaina
Amemorypage,severaltableentrypage(seetablesFigurehaveto2.6)beconsistsupdatedattoleastkeepoftheconsistencypage.framenumber
pageisrepresentingreallythepresentstorageinmainlocationmemoryin,maini.e.ifthismemorymappingandofisaflagvalid.toindicateifthe

PageFrame#State:present/changedAccessRights:e.g.read/write/exec

Figure2.6:Pagetableentryforpurepaging
8TheKbyte.sizeofEarlyapagesystemsisinusedcurrentsmallerprocessorpagesof256architecturesor512bytestypicallyto4saveKbytemainor

ModelMemory2.2

17

memory,butthisalsoincreasesthemanagementoverhead.Theoptimalpagesize
isslowlyincreasingwiththeavailabilityofmorephysicalmemory,howeversince
changingthepagesizerequiresmodificationstotheOS(atleastthisiscurrently
thenorm),itisdoneonlyveryinfrequently.
AgoodexampleofthisslowpacedevolutionistheInteli386,thefirstimple-
mentation(1985)ofwhatisnowcalledtheIA32architecture.Itdefinedthepage
sizetobe4K.Allsubsequentimplementationsofthearchitectureusethispagesize,
includingthePentium4released7almost20yearslater.Todaythe4Kpagesizeisan
unsolvedmajorefficiencyproblem.Manycurrent(2004)processorimplementa-
tionshave128TLBentries,correspondingto512Kofvirtualmemory.Accesses
whichdonofitinthisworkingsetcausecostlyTLBreloadoperations.
Whyispagingmorepopularthansegmentation?Aboveallitissimplertoman-
ageduetothefixedsize.Toloadapage,exactlyonepageneedstobedisplaced
(assumingthatallpageframesareallocated).Thiswasnottrueinsegmentedsys-
temduetothevastlydifferingsizesofsegments.Segmentslargeinrelationtopage
sizeneedarelativelylongtimetobeloadedfromdisc,becausethewholesegment
mustbeloaded.Todaysegmentationisalmostextinct.RISCprocessorsimplement
onlypagedvirtualmemory.SomeRISCspecificationsmentionsegments,butthat
onlyreferstoagroupofpages.Theadvantagesofsegmentswhenitcomesto
protectionhastakenabackseat,intoday’semphasisonperformance.

2.2.8CombinedSegmentationandPaging
Bothsegmentationandpaginghavetheirmeritsandflaws.Therehavebeenat-
temptstocombineboth(e.g.suggestedbyRandell[225]orbyLiedtke[176,178]).
MostKeedyofthem[134]failedproposedtoavoidamajorschemewhichshortcomingscombinesofthebothbaseschemesschemes.orthogonally
withoutwastingtoomuchmemoryduetofragmentation.Theremaininginternal
(whichfragmentationistheiscasefornegligiblestaticasmemorylongastheallocations).externalDynamicfragmentationmemoryremainsallocationlow
canstillcauseexternalfragmentation,butthiswastesonlyvirtualmemory.
looksInthisexactlymodelthepagesameasandwithsegmentsegmentationboundaries(seeareFiguredecoupled.2.7).ThisAvirtualvirtualaddressaddress
isi.e.bytranslatedaddingintotheansegmentintermediateoffsettoaddresstheusingsegmentthestartnormaladdress.segmentationapproach,

Segment#SOffsetinSegmentS
bitswbitss

Figure2.7:Virtualaddressfororthogonalsegmentationandpaging
7forInlarge1993Intelmemoryaddedmapaped4MI/OpagedevicesizeoptioninterfacestothesuchPasentiumframeprocbuffeessorrs,.Itnotisforonlydemandmeant(andpaging.usable)

18Chapter2OperatingSystemConceptsandApplicationIssues

inTheprocessortableofregisters).currentlyEntriesactiveinthesegmentsissegmentpartoftablethe(seeprocessFigurestate2.8)(ideallydescribekeptthe
length,segmenttablestartingentry,addressasandsegmentsaccessplayrights.noroleNoteinthatvirtualtherememoryisnoswapping.presencebitina

AddressLengthAccessRights:e.g.read/write/exec

Figure2.8:Segmenttableentryfororthogonalsegmentationandpaging
addressThebyintermediateusingapageaddresstable(see(ideallyFigureina2.9)isfinallysingle-address-spacetranslatedintoimplementation).aphysical

Page#POffsetinPageP
bitsobitsp

Figure2.9:Intermediateaddressfororthogonalsegmentationandpaging
pageApageframes.tableTheentryaccess(seechecksFigurehave2.10)alreadydescribesbeenthedonemappingthroughthebetweensegmentpagestable.and

Page#PageFrame#State:present/changed

Figure2.10:Pagetableentryfororthogonalsegmentationandpaging
Thiscombinationofsegmentationandpagingretainstheadvantagesofeach
techniqueandminimisesthedisadvantages.Theimplementationeffortrequired
bothinhardwareandsoftwareismoderate.

ModelProcess2.3setAnotherofareaprocessorsof(oneongoinginmostresearchsystems,revolvesbutsomearoundthearchitecturesproblemofsupportusingathousands)certain
effectivelyandefficientlytorunasetoftasksthatimplementthesystem’sintended
whichfunctionalitycreates.theTheillusionnormalofapproachhavingaistoseparateprovideaprocessor“virtualperprocess.processor”abstraction,
createsInitiallyaallfairlyoperatingsecuresystemsenvironmentfocusedbyonisolatingthiskindprocessesofapproach,fromeachwhichother.naturallyPro-
cesseschangeintendinginformation.toThecooperateOSiswithresponsibleotherforprocessescontrollingmustusetheOSflowoffunctionsinformationtoex-
itcanbetweenonlydoprocesses.generalSinceaccesstherightsmeaningchecks.ofThismessagesisisenoughusuallytonotmaintainknownOStotheintegrityOS,,

ModelProcess2.3

19

andareasonablelevelofself-preservationis(althoughrarelystatedexplicitly)the
mostimportantaimofmanyoperatingsystems.
Inmanysystems,processesandvirtualmemoryareintricatelyconnected,in
thesensethateveryprocesshasitsownvirtualmemory.Thisdesignfitsthecur-
rentprocessorarchitectures,butitcreatesproblemswithsharingofinformation
betweenprocesseswithoutgoingthroughtheOSforeveryaccess.

Model-ProcessOut-of2.3.1

Manymodel,inpopularwhichoperatingeveryobjectsystems(or(suchprogram)asUNIXhasitsandownMicrosoftprocess.Windows)Objectsusearethisin-
terpretedasbeingactive,providingaservicetootherobjects.Theonlymeansof
communicationisbysendingmessagesbetweenprocesses.
Everyserviceisexecutedbyatleastoneprocess.Aservicethatisexecutedby
asingleprocessserialisestheprocessingofrequestsandseverelylimitsconcurrent
activityexecutedofbyobjectsseveralusingtheprocesses,service.whichToavoidincreasesthisthebottleneck,numberaofserviceprocessesisfrequentlysubstan-
tiallyactivity.The(e.g.usermajorityinput)ofisprocessesmucharelowerinactive,thanthebecausenumbertheofnumberobjectsoforsourcesservices.of
Processswitchesoccurveryfrequently.
intheSendingOS,sinceandreceivingconceptuallymessagesallthatneedsbetweentobeprocessesdoneisistofairlycopyeasythetomessageimplementfrom
thesendingprocesstothereceivingprocess,andactivatingtheprocessthathas
Thewaitedout-offora-processmessagemodeltoarrive.favoursServiceshavingacanseparateotherwiseaddressremainspacecompletelyperservice.isolated.
objectsThemainwithmanydrawbackofprocesses,theout-ofwhichin-processtheendmodeliscreatesthataitsoftwarefavourshavingmaintenancemany
takingnightmare.allcasesItisofveryhardconcurrencytodescribeintotheaccount.Tinteractionestingisbetweenextremelyprocessesdifficult.preciselyEspe-,
ciallymulti-processservicescarryahighriskofsynchronisationerrors.
Chargingforresourceusage(oranyformofaccounting)isverycomplicated,as
themightactivitycallofotherauserservices.causesMosttheinvocationoperatingofsystemsvariouscanservices,onlyprovidewhichper-servicethemselves
Theaccounting,messagewhichpassingaggregatesparadigmallcanactivitiesbeeasilyregardlessgeneralisedwhichtousercrosscausednodethem.boundar-
toiesbeusingextendednetworktolinks,includethecreatingnodeaidentifierdistributed.Thesystem.OScanObjectthenselectidentifiersthejustapplicablehave
mechanism.deliveryremoteorlocalDefiningmessageexchangefunctionalityasthemainOSkernelinterfaceisacon-
ventionthatbecamepopularwiththeintroductionofmicrokernels,whichaimed
atsmaller,removingsimplermostandofthemorekernelefficient.functionalitySufficetoinsayanthateffortthetofirstmaketheimplementationskernelcode
removedthefunctionalityinawaythatmainlytheoverheadremained.

20Chapter2OperatingSystemConceptsandApplicationIssues

ModelIn-Process2.3.2Ancontextofalternativetheiscurrenttouseaprocess(thus“procedural”calledapproach.in-process).ObjectsObjectscanarebecalledinterpretedintheas
beingimplicitpassiveprocessandswitch,canbewhichpartisofmuchtheOS,easierthetoapplicationunderstandorandlibraries.manage.Thereisno
Thisgrammingstylewithisverysubroutinefamiliarandasitismethodusedcallsinismostveryfamiliarprogramming.Mostlanguages.programmersPro-
tialcaneasilyexecution.deviseItisanmuchalgorithmharderthattosolvesdesignaancomplexout-of-processproblem,solution,assumingbecausesequen-it
problems.concurrencyintroducesintrinsicallyAnenvironmentapplicationiscallschangedothertomakeobjectsthewithinobjectthesameaccessibleprocess.whileitOnlyistheexecuted.addressingPro-
cessestypicallyrepresentusers,soitiseasytoimplementper-useraccounting.
quiredNew(inaprocessespersistentarecreatedsystemtypicallyinfrequentlywhen,onlyanewwhenuseraisnewcreated).parallelTheactivityin-processisre-
modelprocessesmustisstillnotbepossible.confusedThewithain-processsingle-processmodeldoesmodel.notprecludeConcurrenttheuseexecutionofmoreof
thanoneprocesstoimplementasoftwaresystem.
Inanin-processsystem,severalapplicationscancallthesameobject,which
createstheopportunitytocommunicatethroughthissharedobject(ormorefun-
damentally,thememorysegmentcontainingitsdata).Anobjectcanimplementa
messagequeuethatotherobjectsmayuse,implementingmessagepassinginthe
contextmessageofanpassingin-processmechanism,system.whichThesuitsadvantagemany,butisnotthatallthereisapplications.nofixed,central
Generallyanin-processsystemcanbeeasilyusedtoefficientlyimplementan
out-ofin-process-processsystemsystem,cannotbutbenotviceefficientlyversa.Therepresentedlargeinanumbermodelthatpassiveassumesobjectsinactivean
objectssystemsandthiswouldassociatesatexhaustleasttheonesupportedprocesswithmaximumeveryobject.numberInofmostprocesses.out-of-process
thatMicrokernelsmicrokernelsdonottraditionallyhavetofocusimplementonthemessageout-ofpassing-processiswhatmodel.createsOnlyantheout-offact-
processsystem.Themicrokernelideacanbeappliedalsotoin-processsystems.

2.3.3EvaluationoftheProcessModels
Intheprevioussectionsitwassuggestedthatitispossibletosimulateonemodel
withsystemtheislessother,efficienthoweverthansimulatingsimulatingananout-ofin-process-processsystemwithwithananin-processout-of-processsystem.
LauerandNeedham[169]claimthefullsemanticsofboththein-processandout-
ofIn-processreal-worldmodelssystems(althoughthetheyclaimedusedifferentequivalenceofnotions)thearemodelscompletelyisnotapplicable.equivalent.
Assoonaccounting),asthenprocessestheareentityextendedhavingtobepermissionthebasisisofimportant—andprotection(andthisislikewisedifferentwithin

ModelProcess2.3

21

isbothnotthemodels.sameInasthetheout-ofowner-processofthemodel,clienttheprocess,ownerofbutatheserverownerprocessofthefrequentlyserver
serverdetermineshasitsmoreaccessaccessrights.privileges.AclientTocouldavoidindirectlypermissionsgainleakingaccessthistowaydata,,ifeverythe
objectaccessthatisonbehalfofaclientmustbecheckedexplicitly.
Inanin-processmodel,thecurrentlyactiveobjectdefinestheaccessrights,and
thewhereownerearlierofthetheobjectprocessandandthetheprocessobjectsitareinvokedonlyhaverelevantinaccessthetothissensethatobject.some-This
freedomcanbeusedtosimplifyaccounting,sincetheownerofaprocessisatrue
representationforacertainuserofthesystem.
Ramamohanarao[224]hasamoreelaboratecomparisonwiththesameresults.
Inparticularhecriticisestheassumptionofmonitor-basedsynchronisation.

ProcessesersistentP2.3.4Makingtheprocessrepresentationpersistentenablesprocessestosurvivee.g.the
logoutoftheirownerorsystemreboots(whichinaconventionalOSclearthe
processprocessandtable).toKseteeuppingthetheuser’sstateofaenvironment.processItpreservesallowse.g.thetoeffortlogoutspentintothecreatemiddlea
ofaneditingsessionandlaterresumeexactlyinthesamestate.Someapplications
onfairsystemsamountofwithoutcodeandpersistentCPUtimeprocessestoreconstructsimulatethethisprocessbehaviour,state.butthisrequiresa
IBMAnexampleSystem/38ofa[28]system(todayprovidingknownasbothAS/400persistentoriSeries),memoryaandsystemprocessesdesignedisforthe
memorydatabase-intensivemanagement,butapplications.implementThecurrenteverythinginimplementationssoftware.doMostnotofusethathardwaresoftware
issecuritypartofthesystemrun-timerequiresasystemverifiedincludedcompilerwiththewithoutcompilerthe.Suchopportunityatocompiler-basedwriteas-
semblycode,otherwisethesecurityofthesystemwouldbecompromised.

SpacesAddress2.3.5Inthedressablecontextvirtualofmemoryprocesses,.Theitisnotionusefulfortothisdiscussisthetheaddressglobalspace,propertiestheof(potentially)thead-
licationsaddressableonthispartofissue,thevirtualadvocatingmemorycertain.Theremodelshaveofbeenaddressmanyspaces.controversialArelativelypub-
recentManyattemptoperatingtosystemsgeneralisetheimplementaddressaspaceper-processmodelsvirtualcanbememoryfound.inThis[184].(inprin-
ciple)completelyseparatestheprocesses,makingprotectionaprocess-localissue.
Italsosimplifiestherequiredhardwaresupport,becauseitreducesthetotalre-
modelquirementsrelyontojustaccessthechecksneedsinoftheaOSsinglekernelprocess.toAllmaintaindeviationsprotection.fromThethismessagesimple
exchange,filesystemandsharedmemoryimplementationsneedsuchchecks.

22Chapter2OperatingSystemConceptsandApplicationIssues

Anotherapproachthathasgainedmomentuminthelastfewyearsimplements
onlyasingleaddressspace.Allprocessescanpotentiallyaccessallofthevirtual
memory.Variousprotectionmechanismsensurethateachprocesscanonlyaccess
asubsetbasedontheaccessrightsassignedtoit.ThesesocalledSingle-Address-
SpaceOperatingSystems(SASOS,e.g.Angel[197],Psyche[250]orOpal[42])
usuallyimplementpersistentvirtualmemory,someoftheminadistributedsystem.
Theadvantageofdecouplingthevirtualmemoryfromprocessesisthatthevir-
tualmemoryisnot“destroyed”whenaprocessterminates.Thismodelcorresponds
favourablewithpersistentmemoryandespeciallypersistentprocesses.
ImplementingaSASOSisnotasstraight-forwardasthebasicconceptsuggests,
mainlyduetohardwarelimitations.Ifallprocessesshareasinglevirtualmemory,
thenitscapacitymustbelargeenoughtoholdareasonableamountofprocesses
eachwithapotentiallylargeamountofvirtualmemory.Thelimitationsarising
fromthe32bitaddresswidthofthemostpopularprocessorarchitecturearetoday
alltoovisibleforspecialapplicationseveninconventionaloperatingsystems(e.g.
databasemanagementsystems).4Gbyteofmainmemoryisnolongeratechnical
orfinancialproblem(e1000inearly2005).SASOSwithavirtualmemorycapacity
ofonly4Gbyteareclearlyonlyusefulinresearchsystems,tobridgethe(financial)
gaptotheupcomingcheapsystemswith64bitvirtualaddresswidth,givinga
muchmorereasonable16Exabytevirtualmemoryspace.Eventhishugespaceis
limited,requiringcarefulmanagementofthevirtualspaceconsumptiontoavoid
runningoutofspace(see[163]).

Multithreading2.3.6Processesinout-of-processsystemsarefairlyheavyweightconstructs.Processcre-
ationinvolvesasubstantialcost,inbothprocessortimeandmemoryconsumption.
Thestrictseparationbetweenprocessesrequiresexpensivekernelcallstoestablish
communicationbetweencooperatingprocesses.Forapplicationswhichwanttoex-
ploitparalleloperation,thiscostfactorbecomesunnecessarilydominant,because
thecooperatingprocessesoftendonotrequirethishighlevelofprotection.
Toovercomethisstructuringproblem,lightweightprocesseswereintroduced,
calledthreads.Asetofthreadsrunwithinoneprotectiondomain(usuallythead-
dressingenvironmentofaprocess)andcancommunicatethroughsharedmemory.
Threadswitchingisalsomuchcheaperthanprocessswitchingduetothesmaller
amountofstateinformationthatmustbesavedandrestored.Conceptuallyonly
thenormaluser-visibleregistersetmustbeswapped,andsincetheaddressingen-
vironmentisidentical,theTLBentriesdonothavetobeflushed.
Thedownsideisthataprogramusingmultithreadingmustdealcorrectlywith
synchronisationissues,oritwillcrashduetocorruptedoverallstateinformation.
Anotherproblemisthatmanypopularlibraryfunctionsarenotthread-safe.
Multithreadingisessentialtoout-of-processsystemimplementations.Without
thecheapparallelismprovidedbythreads,thesystemwouldconsistofacollection

ModelProcess2.3

23

ofbottlenecks.Ifonlyasinglethreadwouldhandleallrequeststoaparticularser-
vice,thenallrequestswouldbehandledsequentially.Or,viewedfromadifferent
angle,mostthreadsinanout-of-processsystemareintheblockedstate,waiting
forsomethingtodo.Soout-of-processimplementationsofoperatingsystemsjust
havemoreprocessesorthreads,withoutactuallyachievingmoreparallelism.

Interrupts2.3.7Handlingactivitiesefficientlyrequiressignallingthatsomeeventhashappened.
beTheputothertobetteroptionuseifwouldanotherbetouseprocessbusyisreadywaiting,torun.whichwastesInterruptsCPareUtimethereforethatthecan
basisforimplementingprocessesandthesynchronisationwithhardwaredevices.
Themechanismturnedouttobeusefulforallkindsofevents,bothinternaland
andexternalindicatetothethatCPU.anerrorInternaloccurredinterruptsthatrelatepreventstothethecurrentlyprogramexecutedfromcontinuing.instruction,
ExternalInternalorinterruptsareprogram-relatedcausedbyinterruptsperipheralaredevicestriggeredandbytheotherinstructionhardware.beingex-
ecuted(typicalexamplesseeTable2.2).Someerrorsaredetectedbeforethein-
structionhasbeenfinished,andthustheinstructioncanberestartedafterthecause
ofprocess,theerrorandhasthebeenonlythingeliminated.lefttodoOtherisaerrorsmoreorpreventlessgracefulcontinuingcleanup.withthecurrent

InterruptarithmeticclasserrorTdivisionypicalbycauses0,overflow
addressingerrortoaccessatoread-onlymemorymemoryareasareathatarenotinstalled,writing
debugbreakpointinstructionordataisreferenced(atsomeaddress)
invalidinstructionprivilegedinstructioninusermode
Table2.2:Internalinterruptsources,relatedtoinstructionexecution

Externalorsystem-relatedinterruptsaretriggeredbysourcesexternaltoapro-
cessor,withnorelationshiptothecurrentlyexecutedinstruction.Typicalexamples
areinTable2.3.Dependingonthehardwaredevicesissuingtheinterrupts,thein-
terruptratecanexceed10000persecond(thetimerinterruptaloneoccursbetween
100and1000timespersecond).

causesypicalTclassInterruptI/Otimerinterruptinterruptacertaininformationamountisreadyoftimeforhasreadingpassedorwriting
inter-processorinterrupttosynchroniseindividualprocessorsinamulti-
computerprocessorTable2.3:Externalinterruptsources,relatedtohardwaredevices

24Chapter2OperatingSystemConceptsandApplicationIssues

8needsTobetobeablesaved.toInresumemanyexecutionoperating,thesystemsstatethisofistheequivalentcurrentlyincostexecutingtoaprocessprocess
switch,whichmakestheinterrupthandlingcostaverysubstantialpartofthesys-
temload.Reducingtheoverheadofinterruptroutinesresultsinimprovedsystem
executingperformance.processOnthe(andotheraccountinghand,ithandlingasusedCPinterruptsUtime)inthestrikecontexttheofwrongtheone:currentlythe
causeisnormallysomeother,currentlysleepingprocess.
tainApplicationsprogram-relatedgenerallyinterruptsdonottowantimprovetohandlefault-tolerance).interruptsthemselvesInterruptsare(exceptalow-cer-
levelnothingtomechanismdowiththatthecollidescurrentlywithrunningprocess.multiprogramming,Thekernelsincethethereforeeventtakestypicallycarehasof
theyhandlingarerelayed),interrupts(andtranslatinginsystemsthemintowhereprocessdevicedriversactivationsareandexecutedindeactivations.usermode
whichSomeshouldprogrammingnotbeconfusedlanguageswithprovideinterrupts.asimilarSomemechanismexceptionscalled(suchasinexceptionsJava,
NullPointerException)originallystartoutasinterrupts,butgenerallythey
arelanguagesthrownitbyistheusuallyprogramnotpossiblecodetotoindicatecontinueanwhereerrorthesituation.exceptionInhappened.programming

2.4DeviceDriversandFileSystems

Theoperatingbiggestpartssystems,ofbothanyarecoreOSgivenarethespecialdevicetreatmentdriverseitherandtheforfileefficiencysystems.Inreasonsmanyor
asetbecauseofthedriverskerneltoimplementdependsonthetheCPUfunctionalityscheduling.policyFrequentlyandthevirtualkernelmemorydepends.on
thatisWhetherdiscusseddeviceindriverssectionand2.8.fileDevicesystemsdriversshouldandbefilepartofsystemsthearekernelcoreisanelementsissue
ofanpersistenceOSintheandsenseprotectionthatthofeyallcontrolperipheralsconcurrencyand,long-termcommunication,storage.cooperation,

unctionalityFDriverDevice2.4.1Thedutyofdevicedriversistobridgethegapbetweenthesimple“computation
andcontrolmemory”peripheralmodelofdevices.computersThezooandofreal-worldperipheraldevicesimplementations,inventedoverwhichtheneedyearsto
frequentlyintroducednewinterfaceprotocols.Correspondinglyalmosteachand
everyhardwaredeviceneedsitsownpieceofsoftwarethatcontrolsitsoperation
andprovidesareasonableinterfacetotheOSandtheapplications.
arbitraryDevicedriversinterfacehaveofatheperipheralquestionabledevice,honourenrichedofwithtransformingeventthesignallingusuallyusingquitein-
terrupts,intosomethingapplicationprogramscanuse.Beingwedgedbetween
8Externalinterruptsarealwaysresumable,exceptiftheysignalacatastrophichardwarefailure.

2.4DeviceDriversandFileSystems

25

tolow-levelprograms,bitthedevicemanipulation,driverisinterruptinchargeprocessingofalargeandportionhigh-leveloftheOSinterfacesfunctionalityprovided.
Aviouslytafirstsharable).glanceInthefactmajoritymostofdevicesdevicesareseemsharable,tobee.g.non-sharablekeyboards,(discsvideoarecards,ob-
ationssoundcards,runningscannersundertheandcontrolprintersofareasingleshareduserbetweenormultipleseveralusers.interactiveThesharingapplic-
protocolsareactuallymuchmorecomplexthanwithdiscs.
soforSharingflexibilitypoliciesreasonsusedfortheparticularconcurrencyclassescontrolofpartperipheralsshouldevolvenotbeoverparttheofyears,the
firstcoreweredeviceuseddriveronly,butlocallya,separatethenremotecomponent.displayAnfacilitiesexample(suchisasvideotheXcards,Windowswhich
System)wereintroduced.Overtheyearslotsoffeatures(suchas3Dacceleration)
wereTheadded,currenteachtrendwithistoitsreduceownthesharingcountlesspolicy.Allprotocolsthisforausedtosinglephysicalcommunicatedevice.with
withperipheralstandardiseddevices,andphasingflexibleouttheprotocols.legacyThisleadstoimplementationsahighlyandstructured,replacinglayeredthem
USB,protocolBluetooth,suitethatFireWprovidesire,SerialtheAbasisTA/SCforSI,manyconventionalactualdeviceanddrivers.wirelessExamplesEthernet.are

InterfaceDriverDevice2.4.2Somesystems(suchasUNIX)usethefilesysteminterfacetoaccessdevicedrivers.
Thissimplifiestheoverallsystemstructureconsiderably,butontheotherhand
limitsread,thewritedevice,lseekdriverandinterfaceeverythingtotheelseusualthatfiledoesnotoperations,fitwithmainlyioctlopen.,close,
Theotherextremeisaveryelaborateinterfacethatprovidesacustomisedin-
terfaceforaparticularhardwaredeviceimplementation.Theadvantageisthatit
canreflectallfeatureswithminimaloverhead.Thedisadvantageisthatthereisno
abstractinterfaceanymorethatwouldsimplifythedevelopmentofapplications.
Thereisatradeoffbetweenaverydetailedinterfaceandaveryabstractone,
aandthenightmareifapplicationsanew,tendimprovedtoshiftversiontheofbalancethetowardshardwarerequiresabstraction.allItwouldapplicationsbe
usingittoberewritten.Object-orienteddevicedriverinterfaceswithcarefuluse
ofgramminginheritancelanguagesbetweenarenotinterfacesyetcancompletelyhelpwithuptothisthistask,task.howeverCurrentlythenocurrentstandardpro-
programminglanguageseparatestypesandimplementationsenoughnottomess
upthewholetypesystem(cf.thecriticismin[247,143,146]).
Intheprevioussectionthetrendtounifythecommunicationprotocolsandthe
hardwareinterfaceswasmentioned.Thisisreflectedinthedevicedriverinterfaces,
focusingonfairlyabstractinterfacesforrelated,yetdistinctclassesofdevices(e.g.
harddiscs,floppydiscs,WORMs,CD-ROMs,DVDs,DVD-R,DVD-RWandDVD-
RAM).Thisdepartsfromtheapproachthatonlyasingleclassofdevicesisanalysed
whendesigningtheinterface,whichwouldintroducesubtleincompatibilities.

26Chapter2OperatingSystemConceptsandApplicationIssues

unctionalityFSystemFile2.4.3Thepersistentpurposeofmedium.afileInasystemsenseisittoisastore(morespecial-purposeorlessdevicestructured)driver,whichinformationspecialisesona
intheSincestoragediscsofconventionallyvariable-lengthhaveinformation.fixed-sizeblocks,managingthespaceistypic-
allydoesdonenotwithnecessarilyanapproachmeanthatsimilarfiletosystemspaginginaretheconnectedvirtualwithmemoryvirtualcontext.memoryThis
management(todaytheyare,throughmemory-mappedfiles).Thereisatendency
towardsstructuresvery[162].CPaccess-efficient,UspeedbutincreasescomputationallymuchfasterthanexpensiveI/Oschemesbandwidth,suchandastreethe
Aslowlysideeffectdecreasingofthelatencyintendedofdiscaccessesfunctionalityisdominatesthethenecessityfiletosystemsolvemanyperformance.prob-
filelemssystemarisingwasfromtheonlyconcurrentsharableaccessesresourcebythethatdifferentallowedprocesses.commonTaccessraditionallybyseveralthe
processes.Consequentlytherewaspressuretohandletheparallelismbetweenthe
runningapplicationsinasecure,sensibleway.
systems,Lockingimprovingprotocolstheandhandlingtransactionofconcurrentmanagershaveaccesses.beenOtherimplementedsystemsin(suchsomeas
UNIX)haveconsciouslyavoidedthecomplexityofconcurrencymanagement,just
implementingaweak“advisory”lockingscheme.Surprisinglythisworksfairlywell
inreal-worldapplications,anditminimisesthecostoftheoverallimplementation.
computersStartingintheconnected1980s,tothewhennetwork,centralthefilefileserverssystemwereconceptintroducedwasforextendedthepersonalacross
thecomponent,boundariesgivingoftheaccesslocaltoasystem.centralFilefilesystemsrepositorywerethatsplitisineasieratoclientmanageandserverthan
thefileperformancesystemsondifferencesthelocalbetweendiscs.localTheandadvancesremoteinfilenetworksystems.speedobliteratedthe
toToday,non-persistentfilesystemsdataare(suchinasusetheforprocallsortsfileofsystemtasks,inSunironicallySolarisevenorforLinuxaccessthat
representsgrammersarethesocurrentlyusedtotherunningfilesystemprocessesinconceptathatdirectorytheyadaptstructure).itforManymoreandpro-
morepurposesbeyondtheoriginalconcept.

InterfaceSystemFile2.4.4TheinterfacetotheUNIXfilesystemiscomparablysimple.Commercialsystems
oftenhavedifferentaccessinterfaces(e.g.indexsequential).Onmanysystems
severaldifferentimplementationsareavailable,withdifferentpropertiesandper-
formance.Themainfunctions(asimplementedwithUNIX,seealso[232])are:
open:Checksfileaccesspermissions,andallocatesmanagementstructuresand
I/Obuffersinkernel.Optionallycreatesanewfile.
close:Deallocatesthekerneldatastructuresassociatedwithafile.

ManagementResource2.5

27

read:Readsacertainnumberofbytesfromafileintomemory.
write:Writesacertainnumberofbytesfrommemorytoafile.
lseek:Changethecurrentfilereadingorwritingposition.
unlink:representationErasestheismappingdeletedfromwhenaallfilenameprocessestohavethefileclosedtherepresentation.file.Thefile
flock:Placeanadvisorylockonafile,eitherasharedoranexclusivelock.All
theotherprocessesintendingtoaccessthefilemustalsousethiscall,orthe
violated.bewillconcurrencyrequestedThereThisarerepresentsabouttwothedozenmostfurtherfrequentlyfunctionsuseddealingportionwithofthefiles,fileprovidingsystemmeansinterface.to
managedirectories,inter-processcommunication,andprogramexecution.
TheUNIXfilesysteminterfaceisaverysimplerepresentative,othersystems
havegarbagemuchcollector)moredueelaboratetothemoreinterfacesspecialisedwithevenmorefunctionality.artefactsThis(likecontributestheUNIXtothefile
hardgenerallytopredictnon-linearbehaviournatureofoffilethedatasystems,storedbesidinesfiles.theirinabilitytoexpressthetrue,
Topartlyovercomethelimitationsofthetotallyseparatedfilestoragemechan-
ism,manyoperatingsystemsintroducedmemorymappedfiles.Thismechanism
bridgesthegapbetweenpersistentstoreandvirtualmemory,althoughonlyina
isthatrestrictedfilewayread.andFilesarewritestilloperationsconsideredcanflatbebyteavoidedstreams.byaccessingTheonlytheblockimprovementofvir-
tualconcurrentlymemory,buttheitfileishasimpossiblebeentomappedstoreto.trulyDifferentarbitraryprocessesstructuresmaywithusepointersthefileor
references,becausethemappingaddressispotentiallydifferentintheprocesses.
Ptures.ersistentTheCAPvirtual[201]memorysystemwasprovidesonetheofthebetterearliestsolutionforattemptsstoringtomovearbitraryawaystruc-from
theinfluencefileofsystemthefileconceptsystemandideareplaceisstillitvisiblewithainthesinglenotationvirtualusedmemoryin.thatThepaperstrong.

ManagementResource2.5

Ineffectivemostsystemcomputingdesigns.applicationsMostoperatingreasonablesystemsuseofprovideresourcestheis“virtualthekeytoprocessor”cost-
exclusivelyabstractionontoaprocessesprocessor.orSincethreads,itwouldwhichbegivesprohibitivelythemtheillusionexpensivethatfortheymostrunap-
eachplicationsprocesstoinrequireatimelydozensfashion,ofallprocessorsprocesseseacharewiththemultiplexedprocessingontoapowersingleto(orhandlea
few)processorsthroughaprocessschedulerincludedintheOS.Andthecruxis:
icalmostOSaspectshavesuchaasprocessphysicalschedulerandvirtualthatneglectsmemoryotherusageorI/Oapplication-performancebandwidthusage.crit-

28Chapter2OperatingSystemConceptsandApplicationIssues

Thisincreasinglybecomesaproblemsincecurrentlythereisamovementtocon-
solidateseveralserversonasinglecomputersystem(essentiallymovingtowards
anecessarymainframeforconceptseveralwithindividualstandardPCmachines).hardware,Doingthisreducingwiththetheusualmaintenanceoperatingwork
systemscreatestrouble,sincetheyprovideonlycontrolovertheCPUusageofthe
Itisserverimpossibleapplications,tohavebutanomeanslow-prioritytobalancememory-intensivememoryorserviceI/Oandbandwidthhigh-priorityusage.
servicesusingmemoryinanaveragewayonasinglemachine.Thehigh-priority
servicewouldbesloweddownbythememoryhog.
Mainframeoperatingsystems(suchasOS/390byIBM)werefacedwiththese
problems[243]sincethe1970sandthereforecontinuallyimprovedtheirfunction-
alityexceedinginthistheirarea.ThisallotteddoesI/OnotormeanmemorythatfootprintOS/390quicklydetectseandnoughrestrainsforinteractiveapplicationssys-
tems,buttheimplementedalgorithmsworkwellfortheusualdatabase-intensive
systems.mainframetheseofworkloadOnecanarguethatthisissueisnotanessentialpartofageneralpurposeOS,
butrealityprovesotherwise.Alow-priorityprocesscoulddegradetheperformance
ofotherprocessestoalmostzeroifitcausesmemorythrashing.Theresource
onlycontentionresourceprotheblemschedulercausedbyreallyitiscaresgenerallyaboutisCPUunnoticedtime,bybutthetodayOS.theTypicallybottleneckthe
istypicallyI/Operformance(eitherdiscaccessesornetworkbandwidth).
Someresearcherslookatresourcemanagementfromadifferentangle,trying
toguaranteeacertainservicequalitylevel.Qualityofservice(QoS)canonlybe
management.resourceeffectivethroughachieved

SchedulingCPU2.5.1AnOSthatessentialprovidespartofthemostillusionoperatingthateachsystemsprocessistherunsonprocessaprivatescheduler,virtualthepartprocessorof.the
Theimplementedschedulingalgorithmsvarygreatly,dependingontheintended
applicationworkload.Thescheduler(andtheschedulingpolicy)isusuallypart
oftheconfigurablekernelandschedulerthus,butnottheyeasilysupportchangeable.onlyaSomepredefinedoperatingsetofsystemspolicies.providea
robinA,verywherepopulareveryschedulingprocessrunspolicyforforacertaingeneral-purposetimequantumoperating(notsystemsnecessarilyisroundcon-
fromstantorthereadyidenticalqueueforallisselected.processes)Thisandifpolicythatisgivesaelapsed,fairsharethenofthethenextprocessorprocess
timeslicetoallpoliciesisprocesses,thatthesuitableschedulerforneedsinteractiveatimingsystems.source.AspecialEitherthepropertykerneoflalldirectlytime
accessesthetimerhardwareorthedevicedrivertransmitstheinformationtothe
kernel.Allotherpoliciescanbeimplementedwithoutasourceoftimeinformation.
Rschemes,eal-timeinordersystemstohaveguaranteeveryspecialtimelyexecutionschedulersofthatthearesetofusuallyprocessesbasedoncomprisingpriority

Resource2.5Management

29

theapplication.Theapplicationisusuallyfixedandtheworkloadcanbepredicted,
mostofthetimestatically.Alsoreal-timesystemsoftenhaveperiodicallyoccurring
tasks,somethingthatisfairlyuncommon(exceptmaybeonahourlytodailybasis)
systems.operatinggeneral-purposeforProcessschedulingmakesshort-termdecisionsonwhichprocessisassignedthe
CPU.Inoperatingsystemsforlargemachinesthereisalsoamediumtolong-term
schedulerimplemented,calledthejobscheduler.Itstaskistoselectwhichnotyet
activeuserprocess(e.g.asimulationprogramwaitinginabatchqueueingsystem)
willbestarted.JobschedulingallowstheCPUloadtobecontrolledonsystems
withasubstantialnon-interactiveworkload,makingefficientuseoftheCPUwhile
minimisingtheshorttermschedulingoverhead.

SchedulingI/O2.5.2SimilarlytoschedulingtheCPUbetweendifferentprocesses,itcanbenecessary
tosharebandwidth-limitedI/Odevices.Ifcertainapplicationsneedguaranteeson
theCurrentavailableresearchbandwidthtopicsandarelatencyquality,ofothersservicemightneedguaranteestothrottlefortheirnetworkusage.services
that(requiredprovedfortoe.g.beVbottlenecks,oice-over-IPsuchasprotocols).discs.ItSomecanberesearchappliedtooperatingfurtherI/Osystemsdevicesfocus
onresourceschedulingissues,suchasNemesis[171]andEclipse[37].
GenerallyasystemthatonlyschedulestheCPUusageisboundtoexposean-
Tryingomaliesto(sosolvecalledtheQoSproblemcrosstalk),viaasmodificationsdescribedtointhetheCPUintroductionprioritiesistothisfutile,assection.I/O
isperformancegenerallybymuchsloweroverloadingthanthetheI/OCPU.systemUnimportantwithoutprocessesnoteworthycanCPUdegradeusage.system

SchedulingMemoryPhysical2.5.3Theamountofphysicalmemoryallocatedtoaprocessdeterminestoacertain
degreetheexecutionspeed,throughlimitingtheworkingsetavailableforvirtual
memoryusage.Dependingonthepriorityofaprocessitcouldbeusefultogive
certainprocessesmorephysicalmemorythanothers.
whichManytriestooperatingbefairtosystemsallrelyprocesses.onaveryEssentiallysimplisticitallocatesmemoryanamountschedulingofstrategyphysical,
Thememoryneteffectthatisisthatifdeterminedthebyoveralltheworkingmemorysetofusageallpressprocessesuretheexceedsprocessthegenerates.available
Tophysicalmaintainmemory,thenresponsivenessallprocessesunderstarthighload,thrashingitisnecessarysimultaneouslyto.activelycontrol
theeffectivephysicalallocationmemorystrategyallocation,isnotatleastobvious.forInthesomeimportantapplicationsprocesses.alotofDevisingthevir-an
tualmemorymemoryallocations.contentTheissharedallocationbetweenpriorityofaprocesses,particularcreatingpagecanoverlappingchangequicklyphysical.

30Chapter2OperatingSystemConceptsandApplicationIssues

SchedulingMemoryVirtual2.5.4Whentheworkingsetofthecurrentlyrunningprocessesexceedtheavailablemain
memorysize,thevirtualmemorydiscardandreloadoperationsstarttodominate.
MoreandmoretimeisspentwaitingforI/Ooperationsinsteadofcomputing.
EvenInmostprocessesoperatingwhichusesystems,littlevirtualthrashingmemoryaffectsaretheoverallaffectedsystembecausetheperformance.memory
hogsThissaturatemakesthethrashingI/Oasystem,globalblockingsystemrequestsproblem,bysometimesunobtrusivemakingprocesses.thesystem
I/Ocompletelybandwidthusedunresponsive.byaThiscertainisprocessunacceptable,areandnecessary.Vthereforeeryfewmeansoperatingtocontrolsystemsthe
haveThistheisrelatednecessarytoaccountingcontrollingtoolstheandphysicalfacilitiesmemorytoreactmadeontheseavailabletosituations.acertain
ofprocess,physicalbutnotmemorytheissameavailablething(ittheisI/Oonlyifthebandwidthsystemusageisofthrashing).oneprocessEvenifcanplentyneg-
ativelyaffecttheperformanceofotherprocessesthatcompeteforI/Obandwidth.

ManagementEnergy2.5.5Energyisaresourcethathasbeenneglectedinthelastdecade.Itwentoutof
fashioninthelate1980s,whenCMOStechnologytookover,deliveringlow-power,
high-performanceprocessors.Beforethat,powerconsumptionofmainframesand
cooling.liquidrequiredoftensupercomputersExponentiallyincreasingprocessorclockspeedsandconsequentlypowercon-
sumptionrisingatapproximatelythesameratemadepowerconsumptionagaina
problem.An“average”IntelPentium4processor(3GHzclockrateand80Wpower
dissipationarecommonplace)needsalargeheatsinkwithfan.Appleisshipping
cooling.waterbuilt-inwithcomputersManagingthepowerconsumptionisamajorresearchtopicwiththeubiquitous
battery-poweredmobiledevicesthatpeoplefindmoreandmoreusesfor.Allparts
oftheOS(memorymanagement,scheduling,devicedriversetc.)haveagreatin-
fluenceonpowerconsumptionandthereforehavetobetunedtoallowfordiffer-
entpowerpolicies.Sometimestheuseriswillingtoacceptdegradedperformance,
whileinsomesituationsthefullprocessingspeedisrequired.
Multi-processorsystemscandynamicallyadapttheirclockspeedtotheload,
savingoncoolingincomputingcentres.Somecomputerssupporthot-pluggingof
processorsandmemory,whichrequirescontroloverresourceallocation.

Communication2.6

Applicationsoftenneedtocooperatewithotherapplicationsonthesameorona
remotesystemtoprovidetheirservice.Manycommunicationmechanismshave
beendevelopedandimplementedinvariousoperatingsystems.

Communication2.6

31

ationCommunicationbetweenhumans.betweenTherearecomputersmanybearsamutuallystrikingincompatibleresemblanceprotocolsofcommunic-(corres-
pondingtolanguages)whichachieveessentiallythesamething.Theprotocols
themselvesarehighlycomplex.Themainreasonforthecomplexityexplosionis
theThislargesectionnumberdealsofwithpossibletheerrorfundamentalssourcesofinherentinacommunicationdistributedsystems,system.anddoes
notdiscussparticularmodels9orimplementations,e.g.[41].
Communication(oftencalledinter-processcommunication,IPC)caneitherbe
localtoanodeorwithremotenodes.Generallylocalandremotecommunication
mechanismsdifferbothinthesemanticsandtheprovidedinterface.Ultimatelythis
isdueplicationstoOSmorework.implementationManyoperatingdifferencesandsystemsmakesprovideanprogrammingalternativeofdistributedinterfaceap-to
localcommunicationwiththesameinterfaceasremotecommunication.
it)Todayfocusesresearchmainlyinonlooselycommunicationcoupledsystemssystems,(atalsoleastcalledthecomputerdistributedsciencesystems.partTheof
countlesscommunicationprotocolsproposedsofarreflectthevarietyofcommu-
arisenicationfromstylesthethatabstractareusefulcommunicationinthevariousproperties,applications.whichcanThebegeneralclassifiedpropertiesintoa
smallnumberofcategories(seeTable2.4).
OptionsCategoryindirectdirectAddressingasynchronoussynchronousSynchronicityBufferingExplicitnessexplicitunbufferedimplicitbuffered
Table2.4:Classificationofcommunicationsystemproperties
portantThissectionmodelsoffirstclassifiescommunicationusedcommunicationinoperatingstyles,andsystemsthenanddiscussesapplications.someim-

Addressing2.6.1Perhapsthemostimportantaspectincommunicationistoworkoutwhototalkto.
Communicationneedsatleastonesenderandatleastonereceiver.
nicationNamingthepartners.Theparticipantsidentifierdirectlyofiseachthemostcommunicationobviouswaypartnertoisspecifythenodethecommu-address
itisrunningonandtheprocessnumber.
Theproblemisthatthistypeofaddressingisverystatic.Theprocessnumberof
theservermaychangeovertime(e.g.afterareboot).Theclientswouldneedto
benotifiedofthenewaddress,whichisanoneroustask.
9definesAnaexampleprotocolofapstackrotocolconsistingofimplementatisevenonlayers,modeleachisthelayerISO/OSIprovidingareferencemoremodelrefined[124],servicethwhichan
layers.lowerthe

32Chapter2OperatingSystemConceptsandApplicationIssues

Manyimplementationsofcommunicationsystemsavoidtheinflexibledirectad-
logicaldressingandcommunicationuseindirectendpointaddressing.(e.g.aTheport).senderThenamesservertheprocessreceiverassociatesthroughitselfa
withanendpoint,asetupthatcanbereinstatedaftere.g.areboot.Theserver
nodeApopularperformstheimplementationmappingofbetweenindirectthelogicaladdressingisendpointtheportandtheabstraction.receiverP.ortsare
canlogicalonlybeconnectionusedbyaendpointssingleservermanagedtobywaittheforOS.Aincomingportisallocatedconnections.byaItserverencapsu-and
fiedlatesbythetheinternalnodeaddressprocessandnumbertheportofthenumberserverassignedprocess.byPtheortsarenode.uniquelyProcessesidenti-may
sendtoandreceivefromseveralports,implementinggroupcommunication.
systemTheconceptrepresentationofcommunicationchoseninUNIX.portsshouldSocketsnotareberesourcesconfusedwithallocatedsockets,onbehalfthefileof
atheyprocess,canbeandconnectedtheytorepresentaremoteports.port(inSocketsthearecaseofalwaysaclientlocalprocess).resources,although
Amoreflexibleandanonymous,butlesscontrollableindirectaddressingisused
withletterbox.mailboxesThe.AsendermailboxcanisleaveaagloballymessageknownandtheFIFOreceiverbuffercanthatcancollectbetheusedmessagelikea
wheneveritisconvenient.Themailboxallowsforseveralsendersandseveral
receiverstobeactiveonasinglemailbox.Onlythemailboxidentifierneedstobe
known.TheMultiplecommunicationreceiversprotocolscansharecantheimplementworkloadtwoofvariantsprocessingoftheaddressingmessages.(applic-
isabletoslightlybothdifferent.directandIntheindirectsimplestaddressing).case,eachTheparticipantcommunicationnamesitssemanticspartnerofbothwith
everycommunicationprimitive(includingreceive),calledsymmetricaddressing.
Thisresultsinaconnectionbetweenexactlytwoprocesses,becausenounknown
accepted.aresenderssageWithtoandasymmetrictheserveraddressingreceivesthetheclientclientnamestheidentificationserveritalongwantswithtothesendamessage.mes-
Theservercanmaintainconnectionswithseveralclients.

Synchronisation2.6.2Communicationbetweenseparateentitiesrunningindependentlyfromeachother
requiressomecoordinationtomakesurethatcommunicationcanproceedorderly.
Theprecisesemanticsofthiscoordinationbetweenthesenderandthereceiveris
veryimportantforthesemanticsoftheoverallcommunicationprotocol.
Messageexchangecanbeeithersynchronous(sometimesalsocalledblocking)or
).non-blockingcalled(alsoasynchronousSynchronouscommunicationimplicitlysynchronisestheprocessesthatarecom-
municating.Thesenderblocksuntilthemessagehasbeendeliveredtothereceiver
andanacknowledgementhasbeenreceived,andlikewisethereceiverwaitsuntil
amessagehasarrived.Thishastwoadvantages:noadditionalsynchronisation

Communication2.6

33

mechanismsarenecessarybetweenthesenderandthereceiver,andthebuffering
requirementsareminimised,savingmanagementoverheadandmemory.
Ontheotherhand,therearemajordrawbacksofsynchronouscommunication:
•Pwhicharallelismdonotusebetweenthesendermessageandexchangereceiverisfacilitieslimited,canrunonlyconcurrentlysectionsof.code
•Theblockingreceivesemanticsallowsthereceivertowaitforasinglemes-
sagesource.Thisisveryinflexible.
•toTheavoidsenderthisorsituation,receivercangivingupblockafteraindefinitelypredefined.Timeoutstime.Butcanbethismakesintroducedthe
errorprocessingevenmorecomplexandintroducesanotherproblem,namely
whattodoifthemessageisneverthelessdelivered.
Blockingcommunicationissuitableforsimplecommunicationscenarios,where
aclientNon-blockingonlyneedstotalkcommunicationtooneserverestablishes,andnothisserversynchronisationusesonebetweenprocessthepersenderclient.
andlocalreceivertransmit.Thebuffer,sendandtheoperationreceivereturnsoperationasjustsoonasprovidestheamessagereceiveisbufferstoredtointhea
mechanismcommunicationwhenasystem.newThemessagereceiverhasisarrivednotifiedinthethroughreceiveanbufferinterrupt.orasimilar
forThesynchronousinterfacesforcommunication,asynchronousmainlycommunicationbecausearetherelessisnostandardisedstandardeventthanthosenoti-
ficationschemeacrossdifferentoperatingsystems.
Asynchronouscommunicationalsohasspecificdrawbacks:
•spaceManagementcouldleadoftobufferadeadlockmemoryinisthemoreapplication.complicated.AprioriAitisshortageunknownofbufferhow
manybuffersanapplicationneeds,andtheusagecanvarygreatlyovertime.
•sistentSwitchingtointerface,blockingbutthisopeisrationcurrentlyincasetheofbufferstandard.shortageresultsinanincon-
•Programmingcomplexityisgreater,makingtheapplicationlongerandharder
understand.toDuetothelimitationsofblockingcommunication,manyapplicationsareforced
tobyusemanynon-blockingoperatingsystemscommunicationleavesalotwithtoallbeitsdesiredcomplexityinthis.Theareainterfacehowever.provided

Buffering2.6.3Certaincommunicationstylesplaceanassumptionontheimmediatenessofthe
makeinformationsense,andexchange.thereforeSomelimittheapplicationsamountrequireofbuffering,immediatewhileprocessingothersofonlydatamaketo

34Chapter2OperatingSystemConceptsandApplicationIssues

senseifinformationisstored(suchasinemailmessageprotocols).Thebuffering
canleveloccuratinformationeverylikelevel,anfromemaillow-levelmessage.packetbufferstobufferingofapplication-
areTheonlysimplestdeliveredcaseifforthethereceiverOSisistocurrentlydefinethatwaitingmessagesforaaremessageunbufferedto.arrive.TheyIt
sincerequirestheminimalreceiverneedsmemorysomeoverhead,timetobutprocesscannoteveryhandleincominghighratesmessage,ofandmessages,during
thattimeanyarrivingmessageisdiscarded.Thismessagelosscanbefixedby
ofusingabandwidthschemeduethattomessageacknowledgestheretransmissionsreceiptisofeveryunavoidable.message,butacertainloss
ThesimplestimplementationpossiblefortheOSresultsinconsiderableeffortin
theshiftingtheapplications.complexityEverytolineofsomeonecodeelse’ssavedincode.theFromOSisthejustoverallmovedsystemsomewherecorrectnesselse,
pointthereisnothingtobewonwithsuchanapproach.
Higherperformanceandbetterbandwidthusagecanbeachievedbybuffering
canmessages,beprocessedusingabycertaintheprocess.amountofMessagememorybufferstostorearealwaysincomingalimitedmessagesresource.untiltheyTo
avoidhelpsmakinghavingtogooddropuseofmessagestheavailablewhenthebuffers.buffersoverflow,aflowcontrolscheme

Explicitness2.6.4Theinterfacetothecommunicationsystemthatispresentedtotheapplicationhas
agreatinfluenceonthestructureandefficiencyoftheoverallsystem.Insome
situationsitisnaturaltousecommunicationdirectly,whileinothersitdistracts
fromtheproblemtobesolved.
Traditionally,operatingsystemsimplementedallcommunicationmechanisms
betweenprocesses.Tousethem,theprocesseshavetocallOScommunication
functions.ItisclearlyvisibletoboththeapplicationandtheOS(henceexplicit
communication)thatcommunicationfunctionalityisactive.Alldatatransfergoes
throughtheOS(oftenthedataiscopiedfromortothekernelspace).Anextreme
caseofexplicitcommunicationareUNIXsignals[18],whichconveynodata.
Insteadofcommunicatingexplicitly,onecanalsousethememorycontentto
communicateimplicitly.Thememoryblockneedstobeaccessiblebytheparti-
cipatingprocesses.Thisiscommonlycalledsharedmemory,andcanbeseenasa
deliberatedeviationfromtheisolationofprocessesthatisthenorm.Oneormore
processeschangethecontentofthesharedmemoryblock,andtheothersobserve
thechanges.WithalittleOSsupport,efficientsynchronisationcanbeimplemen-
[60].semaphoresusinge.g.ted,Otherimplicitcommunicationmethodsarepossible(anythingthatcanbeob-
servedbymorethanoneprocessissuitable),buttheonlyotherrelativelycommon
mechanismistousefiles.Itpredatessharedmemoryusingvirtualmemory,butis
notlongerpopularbecauseoftheclumsyfilesysteminterface.

ModelSecurity2.7

35

ModelSecurity2.7Theneedtoprotectinformationoncomputersemergedbeforetheyleftthestage
ofbatchprocessingandsequentialcardortape-basedoperation.Theybecame
powerfulenoughtorunseveralprogramsseeminglyinparallel,soseveralusers
couldotherwasworkonrequired.asingleAlsowithcomputerthe.Agrowingmethodcapacitytoofprotectpersistentprocessesstorageagainstitbecameeach
desirabletoprotectfilesandotherresourcesbycontrollingaccess.
canInbetheprevioussummarisedasparagraphatechnicalonlythemethodnotiontocontrolprotectionaccessisused,toandindividualitsmeaningobjects.
Onality,theinteothergrityandhand,securityavailability.meansSecurityamorehasgeneralmanyfacetswaytoandisguaranteenotrestrictedconfidenti-to
managingeavesdroppingaccessontocertaincommunicationfilesetslinks,ondiscs,creationbutandalsomanagementencompassesofpreventionbackupstoof
andavoidsimilaraccidentalobjectives.dataloss,Securitystrategiesgenerallytocontrolcannotattacksbeachievedregardingsimplysystembyavailabilitytechnical
measures,butalsorequiresorganisationalprovisionsnotdiscussedinthisthesis.
securityManagingisgivingsecuritypeopleisnotaccessthetosamethethingdocumentsasprotectiontheyneed,(cf.while[302]).protectionManagingis
concernedwithgivingacomputer’srepresentationofaperson(aprocess)access
toacomputer’srepresentationofadocument(e.g.afileoranobject).
Theobjectsavailabletoaprocessatacertaintimeconstitutesitsdomainofpro-
tection.Asecuresystemdesignmustminimisethedomainofprotection.Itis
sinceespeciallythisopensdangeroustheifsystemnewtoobjectsattackbyTaccessiblerojanbyHorsesother.processescanbecreated,
Another,relativelyunrelatedtopic(exceptthattechnicalmeasuresarevaluable
anaspectsindividualinitstocontrolimplementation)theuseisofprivacypersonal,alegaldatatermstoredthatinadefinescomputertherightssystem.of
Beingapplications.alegalItisterm,usefulthetopreciseprovidedefinitionprotectionofprivacymechanismsvariesthatbetweenhelpcountriesimplementingand
andenforcingarbitraryprivacypolicieswithouthavingtochangetheOS.

Protection2.7.1Withinacomputer,protectinginformationisfairlysimpletoimplementinhard-
ware.Thequestionis,whatisworthprotecting,andwhatmechanismsshould
beprovidedinthehardwareandintheOS.Butbeforeimplementingprotection
systems,onemustbeabletotalkaboutthem.Thisrequiresmakingusablemodels.
Needham[199]firstproposedveryfine-grained,dynamicprivilegesets(aclaim
adoptedbyfewoperatingsystemsduetothecostoffrequentaccesschecks):
“Protectionregimesarenotconstantduringthelifeofaprocess.They
maychangeastheworkproceeds,andinafullygeneraldiscussionthey
shouldbeallowedtochangearbitrarily.”

36Chapter2OperatingSystemConceptsandApplicationIssues

AlaterpublicationbySaltzeretal.[244]coinedthetermprincipleofleastpriv-
ilege,whichdefinestheidealprotectionsystemfromadifferentangle:
“f)Leastprivilege:Everyprogramandeveryuserofthesystemshould
operateusingtheleastsetofprivilegesnecessarytocompletethejob.
orPrimarilyerror.Itthisalsoprinciplereduceslimitsthethenumbedamagerofthatpotentialcanresultinteractionsforanaccidentamong
privilegedprogramstotheminimumforcorrectoperation,sothatun-
intentional,unwanted,orimproperusesofprivilegearelesslikelyto
occur.Thus,ifaquestionarisesrelatedtomisuseofaprivilege,the
numberofprogramsthatmustbeauditedisminimized.Putanother
way,ifamechanismcanprovide‘firewalls,’theprincipleofleastpriv-
ilegeprovidesarationaleforwheretoinstallthefirewalls.Themilitary
securityruleof‘need-to-know’isanexampleofthisprinciple.”
Protectionandsecurityarestillunderactiveresearch,andnewsolutionsfor
today’ssecurityproblemshavebeenproposed[248](focusingonextensibleap-
istoplicationsusesuchcryptographyasWebasabrowsers,cure-all,e-mailwithoutprogramsconsideringandofficeother,simplersoftware).Thesolutions.trend
Securitypoliciesareconstantlyevolving,changingtheprotectionrequirements.
Itissomewhatsurprisingthatessentiallynochangeinprotectionmechanismswas
beregardedinterpretedasasnecessaryanfromindicationtheofarchitecturesmaturityanddevelopedsuitabilityinorthethat1970s.manyThissoftwarecould
ambitions.securitylowhavesystems

ModelMatrixAccessLampson’s2.7.2Lampsonprotectiondescribedsystemsaknownconceptualatthattime.protectionmodel[165]thatwasasupersetofall
termsofAccordingasettoofthesubjects“accessandamatrix”setofmodel,objects,onecanassigningmodelspecificacomputeraccessrightssystemforina
objectscertainareobjectthetoarowssubject.andThiscolumnscanberespectivelyrepresented.Theinamatrixmatrix,elementswheresubjectscontainandthe
assignedaccessrights(seeFigure2.11).

objectsO3O4O2O1S1r,w,x-r,xx
S2-r,xx-
subjectsS3-r,w-r,w,x

Figure2.11:Accessmatrix,describingtheaccessrightsofasubjecttoanobject

ModelSecurity2.7

37

andSubjectsobjectsarerepresentpassiveactiveelementselements(such(aasuserfiles,,amemoryprocessorasegmentsorprotectiongenerallydomain)re-
sources).Thenotion“subject”isinterpretedverybroadlyinmanysystems.They
doingnotcertainhavetodutiesbeintruetheusers,system.butcanCertainalsobeprogramsassociatedcantakewiththelogicalroleofusers,asubjectperform-by
switchingtoadifferentuser(cf.thesetuseridentifiermechanisminUNIX).
detailInfactandtheirLampson’srelationshippapertodiscussesprocesses,theconceptrepresentingofdprotectionifferentdomainsprocessinmodels.great
Theaboveisasimplifiedversion,neglectingthefactthatprocessesmayswitchto
differentprotectiondomains,whichgivesthemdifferentaccessrights.
Themodelinitsoriginalformonlysupportsdirectaccessrights.Thesizeofthe
tableandthefrequentdynamicchangesmakeadirectimplementationinfeasible.

ListsControlAccess2.7.2.1ThemostpopularimplementationofLampson’saccesscontrolmatrixistheaccess
controllist(ACL).Anaccesscontrolliststoresthelistofusersthatmayaccessa
storedcertainlogicallyobject,givingwiththeeachobjectuser10a,itsetisofsimpleaccesstorightschangetothetheobject.rightsSinceassignments.theACLis
Objectsarefrequentlyorganisedin(typicallyhierarchical)directories.Thissim-
vealsplifieslocatinginformationobjects(suchifasonefilecannames)browsethatthroughshouldthebetterbedirectories.keptsecret.HoweverFilethisnamesre-
oftengivehintsaboutthefilecontents,leadingthewaytointerestinginformation
forapotentialattacker.ManysystemsevenmaketheACLvisibletoeveryone,so
theattackerevenknowswhichaccountsgiveaccesstotheobject.Italsoallowsfor
automatedsearchesforincorrectlyassignedaccessrights,i.e.ifsomesubjecthas
arewriteaccesscomparativelytoaneasyobjecttoitattackwouldbynormallysomeonenotwhoneed.hasACLaccessbasedtothesystem.implementations
ject,ACLssotheareaccesspopularrightsbecausecantheyeasilyarebeeasychangedtobymanage.anyoneTheyare(potentiallystoredanywiththesubject,ob-
dependingonthemetarights)whoknowstheobjectidentifier.Revokingaccess
rightsisstraightforwardandcanbedoneinstantly.Thechangeiseffective(al-
openmost)operation,immediatelybut.Manythatisgenerallyimplementationssufficientonlywithverifythethetypicalaccessshortrightsonlifetimethefileof
processes.Filesareimplicitlyclosedwhenaprocessexits.
AppleAlmostMacOS)alluseoperatingittosystemsrepresent(suchtheasaccessallUNIXcontrolforvariants,filesendMicrosoftprocesses.Windowsand
ForsomeOSfunctionstheACLisfixed,i.e.thereisastaticruledefiningwho
mayperformanoperation,andforothersitcanbeuser-definedinamoreorless
writeflexibleandway.executeUNIX,andrestrictsalsoonlytheaccessdefinesrightsthreeclasses(ignoringofmanysubjects,minornamelydetails)thetoownerread,,
10fileManysystemactualstructure.implementationsstoreitinthedirectoryentriesusedtoorganisethehierarchical

38Chapter2OperatingSystemConceptsandApplicationIssues

groupandothers.EveryACLgivingaccesstoaUNIXfileisrepresentedby9bits,
plustheownerandthegroupsettingforthefile.Thereisanextensiontothis
limitedACLimplementationinUNIX,specifiedinthe(withdrawndraft)standards
IEEEPOSIX1003.1e[115]and1003.2c[116].Thesestandardsonlyimprovethe
fileaccessrightssystem,butdonotchangethefixedACLsformanysystemcalls.

ListsCapability2.7.2.2everyLampson’ssubjectaccesshascontrolinformationmatrixoncanwhichbealsoobjectsitcanrepresentedaccessanddifferentlywith,whatnamelyaccessthat
rights.AThiscapability(firstimplementationpublishedisincalled[58])iscapabilityapairlist.consistingofanobjectidentifier
onandantheobject,accesstherightscapabilitygrantedhasontobethisshownobject.toWhenproveanthattheoperationaccessisistobelegitimate.invoked
Manyideasoncapability-basedoperatingsystemsareinfluencedbyCAP[200,
202],complexwhichsoftwareimplementsobjectsbothusingthecapabilities.accessrightsPersistentsystemforobjectssegmentsaremanagedandforwithmorea
specialInthefilefirstsystem,place,whichgivingisancapableaccessofrightstoringforacertaincapabilitiesobjectsecurelytoa.subjectdoesnot
inmeandifferentthatitcanprotectionusethisdomains,accessrightaccordingatanytothetime.principleCapabilitiesofleastcanbeprivilege.managedIfa
capabilityCapabilitiesiscancurrentlybenotinterpretedaccessibleasthensufficienttheobject[203]itorprotectsnecessaryisalsoconditionsinaccessible.for
gainingpredictable,access.butIftheasystemcapabilitycanisbesufficientmademoreforaccess,secureifthenfurtherthebehaviourconditionsiscanmorebe
addedbeforeanaccessispossible,makingtheprovisionofacapabilityanecessary
Thecondition.Thiscontroversialcanbeuseddiscussione.g.ontothisrestrictcontextaccesshastonotanbeenobjecttosettledofficesofarhours..Capab-
ilitiesintheiroriginalformareearly-boundaccessrightsdecisions(i.e.havinga
bycapabilitydeletingisthesufficient).objectandOncemakingasubjectsurehasthataitscapabilityidentifier,itisisneverimpossiblereused)to(otherrevokethan
accesswithoutcooperationfromthesubject.Thisisthewell-knowncapabilityre-
vocationproblem,whichhasplaguedmanycapability-basedsystems.
levelVofariousindirectionsolutionstointothistheproblemaccesshaverightsbeenlookupsuggested.step,placingMostofitthemunderputancontrolextraof
thefixedownermetarightsoftheobject.assignmentThisandisnotalsoareintroducesgeneral-purposecentralisedsolution,control.sinceitassumesa
whichThereareencryptstwothemajorcapabilitywithimplementationapasswordvariants(orofmorecapabilitygenerallylists.aThecryptographicvariant
signature)protection.isTheirpopulardisadvantagebecauseitisallowsthatthiscapabilitiesimplementationtobestoredisonly[12]withoutprobabilisticallyfurther
secureagainstforgingofcapabilities.Allsuchimplementationsneedacentralcap-
toabilityretrievetabletheintheassociatedkerneltoaccessverifyrightstheiftheycorrectnessareofstoredaincapabilitythetable).(andsometimes

ModelSecurity2.7

39

Theotheroptionistostorecapabilitiesinataggedarchitectureorinprotected
CALsegments,[167],CAPsegregated[200,or300,partitioned301]andfromHYDRAnormal[306,data308].(cf.[173]).IntegrityThischecksisusedcanbein
omitted,attheexpenseofamorecomplexmemorymanagement.Operationson
capabilitiescanbeimplementedinmicrocodeorthekernel.
toTheverifybigtheadvantagepermissions.ofThecapabilitiesaccessisthatrightstheychecksneedcannobecentralperformedinformationwithout[136]find-
ingorganisetheobject.theminCapabilitieswhateverwayareitstoredlikes.inTheretheisnoenvironmentsystem-definedofthesubject,structurewho(typic-can
allyThisminimiseshierarchical)thefortargetobjects,forwhichattackers,canbesinceevenbrowsediftheygetconceptuallyaccessbytoeverytheaccount,subject.
thecapabilitiesmaybeorganisedsothattheycannotbeeasilyfoundorfreelyused.
ThegeneralconceptofacapabilityshouldnotbeconfusedwiththePOSIXcap-
andabilities1003.2cspecified[116].intheTheyarea(withdrawnverydraft)peculiarstandardscapabilityIEEEPOSIXimplementation1003.1etocontrol[115]
accessrestricttothetheUNIXsuperusersystemandtocallsgiveavailable“ordinary”totheuserssuperusersome.ofTheythecansuperuser’sbeusedtopowers.both

ModelRuleAccess2.7.3basedSupportaccessforarbitrarymodelstoaccessberulesspecified.wasThisproposedcannotinbe[75],expressedallowingwitharbitraryLampson’srule-
canmatrix,bebutusedtoallowsconfinemuchthemoreflowofgeneralinformation.andabstractLampson’sdefinitionaccessofmatrixaccessisarightssubsetand
oftheaccessrulemodel.Arbritraryconditionscanbespecified,usingpredicates
includingquantifiersandsimilarmathematicalabstractions.
performHenceonancomplicatedobject,extendingpreconditionsLampson’scancontrolmatrixthemodel.accessTherightsrulesaweresubjectwrittenmay
asCONDITION:SUBJECT→OBJECT.ACCESS_RIGHTS.
Theexamplesintheoriginalpaperalsousedsemanticaccessrightsinsteadof
directsoftwareaccesssystems.rights.SoItfarfitseasilyhoweverintoitthehasnotbeenobject-orientedadopteddesignbyanymethodoftheofpopularcurrent
operatingsystems,butcouldremedymanysecuritydeficiencies.

ControlAccess2.7.4systems,Differentdependingapproachesontothecontrolintendedaccesstomanagementobjectsinastyle.systemTheareaccessusedcontrolinsoftwaremodel
definesCurrentlywhoisaccessinchargecontrolofmodelsdefiningarethebeingaccessrights.implementedthatgivetheoriginator
oftheinformationcontrolovertheaccessrights(intendedtosupportlicensing
ofagementinformation(DRM)orrelyonsoftware).cryptographyThecurrent.Theseareimplementationsnotcoveredofindigitalthisrightsthesis,man-but

40Chapter2OperatingSystemConceptsandApplicationIssues

alternativesbasedontheaccessrulemodelwillbeshown.
Thefollowingaccesscontrolmodelscanbothbeimplementedwithdirect(i.e.
ingspecifyingrulesthattherightsdetermineexplicitlytheonrightsaofcase-by-caseusers)accessbasis)rights.andTheserule-basedtwo(i.e.aspectsspecify-are
orthogonal.Thecommoncombinationsaredirectaccesscontrolwithdiscretionary
accessspecification,rightbutspecificationtheotherandcombinationsmandatoryareaccessalsocontrolpossible.withrule-basedaccessright

ControlAccessDiscretionary2.7.4.1Thesimplest(althoughnotthemostsecure)waytoimplementanaccessrights
ofsystemtheisdata.toThisdelegateistheallmostresponsibilityappropriatetotheimplementationindividualinusera,systemtypicallywheretothesecurityowner
mostlyLettingmeansthethatownertheofauserfilegivesdefineothertheusersaccessaccessrightstotohisitfilesatashisheseesdiscretionfit.isap-
studentpropriatecaninmakeenvironmentshisownlikeadecisionuniversitywhat,towhereshareeachorkeepmemberprivate.ofstaffTheandlowesteach
commondenominatorinsuchanenvironmentistolettheownerofafiledecide.
onInaprotection.personalMicrosoftcomputerWsystemindowswith3.xandtypically9xasingleimplementeduseronlylittleasingleemphasisuserisputse-
thecuritysinglemodeluser,thatitisnosupportedproblemtoread-onlychangefiles.theaccessHoweverrights,sincee.g.everywhenfileavirusbelongedtriesto
toinfectthesystem.Toachieveamorerobustsystem,itcanbearrangedthate.g.
theOSfilesbelongtoaseparateuser(usuallycalledsystemadministrator)and
theaccessnormalcontrolusersystemsdoesnotcanhavepreventtherightunintendedtooverwritemodificationsthesetofiles.certainEvensetsveryofsimplefiles.

ControlAccessMandatory2.7.4.2Dependingonthesecuritypolicyrequiredbytheapplication,discretionaryaccess
doescontrolnotisnotbelongtoappropriate.him(inaveryGenerallylooseeverysense)timebutthetotheuserhandlesorganisationheinformationworksthatfor,
thereisdemandforamorecentralcontroloveraccessrights.Atypicalexample
areMandatorymilitaryaccessinformationcontrolprocessingenforcesasystems.globalsecuritypolicythatisdefinedbyan
organisation.Theaccessrightstoindividualobjectsmaydifferdependingonthe
subject,butthe(typical)usermaynotchangetheaccessrightsofanobject.
Thesystemtakescareofallaspectsofaccessrights,followingacertainpolicy
rights,typicallybutthisexpressedapproachbyaissetnotofveryrules.Itcommon.wouldbealsopossibletousedirectaccess
signedManytocontrolmandatorytheaccessflowofcontrolinformation.systemsoftenObjectsfollowaretheclassifiedlatticeintomodeldisjoint[57],sets,de-
andobjects.theItusersisaareallowedgeneralisationtoofperformthefamouscertaintransfersBell-LaPofadulainformationmodel[25].betweenAnotherthe

ModelSecurity2.7

41

lativemandatoryregulationsaccesstocontrolpreventsystemconflictsthatofisusedinterestinisthebusinessChineseWenvironmentsallpolicyand[32].legis-
Veryfewoperatingsystemssupportmandatoryaccesscontroldirectly,andeven
typesthoseofthatdocustomers.oftenalsoHavingprovidetwoaccessdiscretionarycontrolaccessmechanismscontrolintoplaceaccommodateconcurrentlybothis
dangerous,becausetheycanpotentiallybeplayedoffagainsteachother.

RightsAccess2.7.5Inordertobeabletochecktheaccesspermissionsofasubject,itmustbeknown
whataccessrightsthissubjecthas.Thesetofaccessrightsavailablevariescon-
siderablybetweensystems.Thissectiondefinesthenotionproperlyanddiscusses
differentaccessrightssystemsusedinanOScontext.
Someaccessrightsaresupportedbythecurrentprocessorarchitectures,while
othersmustbeimplementedinsoftware,becausetheyhavenodirectrepresenta-
tioninthecomputerhardware.Thisimpliesthatsomeaccessrightssystemsare
cheaperthanothers.Howevercaremustbetakennottocompareappleswith
oranges,sincerightsarecheckedatdifferentplacesandwithdifferentfrequencies.

RightsAccessDirect2.7.5.1Theseaccessrightsarederivedfromthelow-leveloperationsprovidedbythehard-
warepermissionsorthebothcoreforOS.Mostmemoryoperatingsegmentsandsystemsfiles.Theyimplementhavereadlittle,inwriteandcommonexecutewith
thestructureoftheinformationtobeprotected.Ontheotherhand,theyarecheap.
Declaringthislow-levelmechanismanOSconceptwillresultinasimplisticpro-
tectionmodelthatcannotrepresentthetrueprotectionrequirementsofreal-life
file,systems.butthisE.g.acannotuserbefrequentlyrepresentedshouldwiththeonlyfilebeaccessabletorights.modifySplittingcertainthepartsfileofintoa
partswithseparateaccessrightsisnotageneralsolution.Application-levelaccess
rightschecksareonlyeffectiveiftheyarenotcircumventable.

RightsAccessSemantic2.7.5.2Real-lifesecuritysystemscanbemuchmorepreciselydefinedbytheabstractoper-
ationsthatareallowedtoauser.Inthe1970s,whenthebasicdesignofthecurrent
operatingsystemshasbeenlaid,theprogramsweremostlyunstructuredamounts
OS.thetocodeofThereforetheonlychoicewastodefinelow-levelprotectionmechanisms,inthe
hopethatprogramsusetheminternallytoimplementacertainsecuritypolicy.
Inthe1970stheideaofabstractdatatypesappeared.Firstitwasonlyusedto
helpwiththegrowingsoftwareengineeringproblem,namelyprogramcomplex-
ity.Keedy[130]appliedthistothewholesystemdesign,deliberatelyshiftingthe

42Chapter2OperatingSystemConceptsandApplicationIssues
focusawayfromindividualprograms.Itisimpossibletoaccessdatadirectly,a
mechanisms.protectionhigher-levelforprerequisiteTheinterfaceofanabstractdatatype(ifitiswell-designed)usuallyhasoper-
ationswhicharepartofanatural-languagespecificationoftheintendedsecurity
ationssystem.onThusthetheysamearefileanallowedidealtobasisfordifferentprotection.usersareTheeasilydifferentrepresentedkindsofbymodific-appro-
priateinterfacemethods.AnexampleisshowninFigure2.12.
OpenAccountCloseandNameAccountAddress?OverdraftDepositLimit?BankofSetAccountsCurrentithdrawWBalance?AddransferTInterestAuthoriseOverdraftFigure2.12:Semanticaccessrightsexample:bankaccountsinterfaces
Usingfine-grainedthedecision.interfaceThemethodsTableas2.5theshowsbasisforpossibleaccessaccessrightsrightsallowsaassignments.muchmore
InterfacemethodTellerBranchH.O.H.O.
AuditorAccountantManagerOpenAccountyynn
CloseDepositAccountyyyynnnn
TWransferithdrawyyyyynnn
AuthoriseOverdraftnynn
AddCurrentInterestBalance?ynynnyyn
OverdraftLimit?yyyy
NameandAddress?yyyy
Table2.5:Semanticaccessrightsexampleforbankaccounts

ModelSecurity2.7

43

RightsAccessGeneric2.7.5.3Thethatsetcontrolofaccessaccessrightspatternsareusuallycommontoallcomplementedobjects,withsuchaassmallcreateset,ofcopyaccessanddeleterights.
Insimpleimplementationstheseoperationsaretreatedspecially(e.g.inUNIXyou
maycreateanewfileifyouhavewriteaccesstothedirectory).
cessInarightsmorecanbegeneraltreatedjustimplementationliketheusingothersemanticsemanticaccessaccessrights,rights.theThegenericonlytrueac-
tothedifferencewhole(butobject,irrelevantwhileforthetheusualaccessoperationscontrolsystem)accessisonlythatathepartofoperationtheobject.applies

Metarights2.7.5.4toAccessdefinerightswhomaysystemsinchangerealaccesslifecannotrights.beSpecialstatic.careThemustpurposebeoftakenthenottometarightscreateis
loopholesbygivinguntrusteduserstherightto“helpthemselves”.
areForoftensimplicityeitherfixedreasonsor(foronlytheallowOS,verynotforsimpletheuserrules.orFrequentlyapplication)theretheisametarightssuper-
userobviouslywhohasverythedangerous,implicitsincenon-revocablethismakesrightthetosuperuserchangealltheaccessmostrights.trustedThissubjectis
inreader).thewholeAdditionallysystem,(whetherhavinganthatomnipotentassumptionholdssuperuserinthepreventsrealworldsecureisleftsharingtotheof
asinglecomputerbyclientswithdifferentsecuritypolicies.
eitherThearesultveryoflooseansecurityinadequatesystemormetarightsaverysystemtightoneimplemented(unlesstheintheapplicationOSisoftenhap-
penstofitintothetemplatebychance).Bothcasesareasecurityrisk,becausein
theusersformercantoochangemanyusersthem—puttingcanachangehighthemanagementaccessrightsburdenandoninthethefewlatteruserstoothatfew
cando,creatingthechancethatincorrectmodificationsareaccepted.

ModelSecurityaImplementing2.7.6design.ChoosingaManyrealisticsystemssecurityarebuiltmodelonforoperatingasystemsystemsisanwithaimportantverypartsimpleoftheprotectionsystem
tomodel.theWusers,ideningwiththetherulesassumptiontowhatthatisdirectlyreducingtheimplementableriskisnotgivesworthtoothemucheffort.access
Theotheroptionistoimplementanadditionalsecuritylayerontopofwhatthe
OSWithoutprovides.aThistrustableposestheimplementationriskofofloopholesthebetweenprotectionthesystemtwolayers.(ideallyinasmall,
easilyinspectableorevenprovablycorrectsecuritykernel[11]),securityisalways
Infactquestionable.MicrosoftWInterestinglyindows,,UNIXthereandarenotMacOSmanyarefairlysecureinsecuresystemsinoperatingcommonsystems,use.
E.g.theintentionallysecurityso,becauseadvantagetheyofthesacrificeMicrosoftsecurityWforindowssimplicitykernelorislostconveniencethisway.ofuse.

44Chapter2OperatingSystemConceptsandApplicationIssues

Confinement2.7.7Simpleaccessrightssystemscancontrolwhohasaccesstoacertainpieceofin-
formation,butcannotcontrolwheretheinformationflowsto.Anyuserhaving
readaccesstoinformationcancopyittoanotherfile.Actuallyanyprogramstarted
bytheusercanbeaTrojanHorse,whichcantrytostealinformation.Theprinciple
ofleastprivilegecannarrowdownthescopeoftheproblem,buttheloopholein
manysystemsisthatcreatingnewfilesisstillpossible.
Confiningtheflowofinformationisimpossibleinmostsecuritymodels.Theonly
modelthatiscapableofexpressingitingeneralistheaccessrulemodel,whichhas
aconfined_topredicatetodescribethealloweddestinations.
Frequentlyconfinementisneededwhenuntrustedcodeneedstobeexecuted.
Codefromunknownsources(suchasanexecutableemailattachmentthatmight
containaworm)wouldbenolongerasecuritythreat.Iftheprogramisexecuted
inaveryrestrictedenvironmentitwouldposenodangertosecurityandwould
showitsbehaviourquickly.Accesstotheuser’snormalfilesandtothenetwork
wouldbeforbidden,topreventspreadingapotentialworm.Someprogramsmight
evenbeusedpermanentlyinsuchanisolatedenvironmentifthesupplierisnotto
betrusted,buttheprogramistoousefultobescrapped.
Implementingconfinementconditionsisharderinout-of-processsystems,asthe
protectiondomainaprocessbelongstowouldneedtochangewitheveryrequest.
Within-processsystemstheconfinementconditionscanbecheckedattheinvoca-
tionofanoperation.Anunsolvedproblemishowfurthercallscanbecontrolled.

ChannelsCovert2.7.8Nomatterhowtightasecuritysystemis,restrictingflowofinformationtoonly
thesubjectswhoshouldhaveaccess,therearealwaysunintendedmeansofcom-
munication,calledcovertchannels,whichcannoteasilybepreventedormonitored.
Communicationispossibleifthereceivercansomehowobserveinformation.It
doesnotmatterifthisobservationisintentional(asinthecaseoftheusualcom-
munication,controlledwithaccessrights)orunintentional.
AcaseofunintentionalcommunicationisthataTrojanHorsetransmitsinforma-
tionthroughthetimingbehaviourofitsown(algorithmicallycorrectlyimplemen-
ted)interfacetotheattacker.Informationcouldbetransmittedinsomethinglike
a“Morsecode”,modulatingandobservingtherun-timeofaninterfacemethod
directlyorindirectlyaccessibletotheattacker.
Intheliteraturetwoclassesofcovertchannelsaredistinguished.Themostob-
vious(althoughalsotypicallywithalowerusablebandwidthduetoscheduler
interference)isatimingchannel,wheretheinformationisdeducedfromtemporal
behaviour.Theothervariantisastoragechannel,inwhichtheattackercandir-
ectlyobservechangestoan“attribute”thatisnormallydeemednon-critical.This
cangoasfarasmeasuringthepowerconsumption,whichformodernprocessor
architecturesishighlydependentonthecodeexecuted.

ModelSecurity2.7

45

Kemmerer[155]devisedaschemetosystematicallyanalyseacompletesystem
forThiscovertschemeischannels.usedAinaseparatemoresteppracticallyisdecidingorientedwhattoanalysisdoofagainstasystemcovertforchannels.covert
channels[190],developedinthecontextofmilitarycomputersystemsecurity.

rustT2.7.9Inthedesignofsecurity-sensitivesystemsalotofeffortisspentestablishing(orde-
fining)trustrelationshipsbetweencomponents.EspeciallyintheOScontexttrust
theplaysanwholeessentialsystemisrole:notatsomefunctional.stageTrustusersishavethetoverybebasegivenofaccesssecurityto,intheresourcessenseor
thatanuntrustworthysecuritysystemisasgoodashavingnoneatall.Asecurity
plexsystemsecurityshouldbesystemstrustable,alwaysandleavethisatracedemandsofadoubt,certainbutthestructuralreverseisnotsimplicity.generallyCom-
thetrue.trueVerysimplerequirementssecurityandaresystemsthereforearefrequentlyinsecure.notpowerfulenoughtorepresent
generalityEstablishing.Specifictrustisonefunctionalityofthethatdilemmasshouldthatbeistrustableimpossiblemusttobesolveselected.withcompleteActually
therearetwocomplementaryproblems:thesystemmustbetrustworthyforits
usersprovideandmeanstheforsystemthehaslatterto,sinceconfirmthesecurityisidentitygenerallyoftheuserviewed.asMostprotectingsystemsonlythe
datasystem.fromunauthorisedConfidence-buildingaccess.Inmeasuresthecontextwouldofincreaseprivacytheusersalsoacceptancehaveoftoatrustsystem.the
thatRecentlycertifyitthatbecamethecodepopularistoauthenticuseandschemeshasnotbasedbeenonpublicmodifiedkeybyanyonecryptographysince
release.Ahierarchyofdigitallysignedcertificates(asocalledpublickeyinfrastruc-
ture,systemsPKI)iswhichmeantusetothisautomateapproachtherefusetoverificationacceptprocessunsignedforcodesignatures.oratleastOperatingcom-
intoplaintheloudly.certificationWithcurrentprocess,whichimplementationsinvolveshumanhoweverthisfactorsjustthatshiftscantheleadtoweaknesserrors
(aprominentexampleisdescribedin[92]).
PublickeycryptographyandPKIcannotautomaticallyheightensecuritydueto
isthesound,uncontrollablebutthereal-lifeenvironmentandimplementationtheunclearhasproblems:definitions.whatThedoesgeneralasignatureapproach
mean,whatdoesacertificateactuallycertify?Howcanthecomputersinvolvedin
themaliciouswholeends?processAbegeneralprotectedcriticismagainstoftheTPKIrojanHorsesapproachthathasbeenmisusethepublishedsecretinkey[68],to
andafurtherarticlewitharelatedtopicisin[69].
tureEffectively[283]:ityouboilscanonlydowntrusttothesoftwaremoralofyouKenhaveentirelyThompson’sTwrittenuringAyourselfward(andLec-
thisalreadyassumesthatonemakesnomistakes).Trustingdevelopmenttoolsin
theparticularwholeissystemdangerous,securityissinceatifperil.theycontainself-replicatingTrojanHorses,then

46Chapter2OperatingSystemConceptsandApplicationIssues

Authentication2.7.10sense:CurrenttheOSoperatingensuressystemsthatcareonlytheaboutauthegenuineusernticationgetsexclusivelyaccesstointheandata,butasymmetricaldoes
notcarewhethertheusertruststheOS.
Thisdevelopedstillbyappliesthetotrustedsystemscomputingwiththeplatformcurrenthypealliance,aroundTCPA.theItistechnologytechnically[285]im-
plementedasachipintegratedintothecomputertostoreandverifyauthentication
keys(usedtoverifythesignaturesforapplications).Onlytrustedapplicationsmay
accessthisstorage.Currentlyimplementingdigitalrightsmanagementwiththis
basispromisesisthe(suchmostascredithatblejustbecauseimprovementofoververifyingcurrentsignaturesoperatingthesecuritysystems.ofAllapplica-other
OStionsoverwillthebeimproved)applications,arebuthazynotatthebest.Thetrustworthinessapproachoftheincreasessystemthetothecontroluserof.the
IdealOtherwiseoperatinganyapplicationsystemsshouldprogramcanestablishe.g.amimictrusttherelationshiplogininprocedurebothofthedirections.sys-
temandrejectitasinvalid,toharvestusername/passwordcombinations.
userAnmayunusualdefineitsapproachownhasbeenauthenticationusedinthemethod.MONADSThefactsystemthatthe[141],user’swhereprocesseveryis
persistentisusedtohaveaper-userauthenticationmethodthatisinvokedasthe
processisreactivated.Thismakesitmucheasierforeachusertodetectamock-up
isloginnocentralprogram,passwordsimplytablebecauseoritothercannotcopyauthenticationbehaviouritcredentialshasnoaccessrepositoryto.,whichThere
makesitmuchhardertocompromisemorethanoneaccount.
andGiventhethecomplexitydevastating,toprotectrepeatedcentralresultsfromauthenticationsurveysoninformationthequalityofadequatelypasswords11,it
ismandatorytoprovidebettersecuritywithoutnaggingeveryuserto“usebetter
passwords”.AccountingTheiscloselydecentralisedrelatedwithauthenticationauthentication,isveryasitpromising.requirestrustableiden-
tificationoftheuserthatshouldbechargedforresourceusage.Manyoperating
issystemsonlyacannotroughprovideapproximation.asuitableThisbasisalsoformakesaccountingfine-grainedandthereforeauditingtheofaccountingactivities
inattacksthesystemagainstverythehardsecurity(e.g.systemsecurityarealmostauditing).Asimpossibleatoconsequence,detect.certaintypesof

Structuring2.8

Choosingtherightsoftwarestructuretomatchthepurposeofthesystemisaprob-
lemmuchharderthanitseemsinitially.Theresultisthatmanysoftwaresystems
11MorrisandThompson[194]found1979thatonly14%ofthepasswordsweresecure,andin
1989Riddleetal.[231]reconfirmedthis.FeldmeierandKarn[81]demonstratedthetechnological
modernadvancesincomputerbrute-forcehardware.passwordFairlylongcracking,bypasswordsimcanprovingbethecrackedalgorithmwithinhoursimplementationordays.andusing

Structuring2.8

47

use“theonlypossible”structure,whichisonedictatedbyeithertheOS,amiddle-
wareframework,ortheknowledgeoftheprogrammers.
Softwareengineeringskillshaveimprovedconsiderablyoverthelastdecades,
howeverthishasnotresultedinguidelinesforstructuringlargesoftwaresystems,
buthelpedwithdecomposingaproblemintomanageableportionsandclassdesign
guidelines.Whilethishasdefinitelyimprovedthesituation,thereisstillagap
betweentheoverallsystemstructureandthedesignofthesmallcomponentsthat
havetobeimplementedintheprogramminglanguageselectedfortheproject.
Middleware(suchasONCRPC[269],DCERPC[211],CORBA[209],SOAP[304,
305]or.NET[220])isadopted(ordeployed)withoutconsideringthesideeffects
ontheoverallsystemdesign.Thisisespeciallyseveresinceallthementioned
approachesbaseonthemessagepassingmodelandruleoutallothermodels.
Itshouldbenotedthatforagoodsystemabalancebetweensize,complexity,
efficiencyandcontrolmustbefound.Regularlyitisproposedthatoperatingsys-
temsmustbemadesimpler,givingtheapplicationsmorehandletousetheavail-
ableresourcesefficiently(e.g.byLampson[164,168]).Thisindicatesamismatch
betweentheservicesprovidedbytheOSandthoserequestedbytheapplications.
Itmustbecarefullyexaminedwhethertheapplicationlegitimatelyclaimsmore
control,orifitisjustacaseof“withaspecialOSjustforthisapplicationitcould
bemademoreefficient”,whichviolatestheaimsofageneralpurposeOS.

SystemsLayered2.8.1Theveryfirstapproachtotacklethesoftwareengineeringproblemwastouse
a(hopefully)layereddesign.morepowerfulConceptuallyand/oreveryeasierlayertouseprovidesthantheanlowerabstractlayer.Themachinebasethatma-is
chineisdeterminedbytheavailableprocessorhardware,andthetargetmachine
isthemethod,ascompletethedetailsapplicationofthe(seeapplicationFigureare2.13).typicallyThisfavourschanging.aThebottom-updesigndesignstarts
withpowerful,generallyusefulapplication-specificlow-levelfunctions.functions,whicharecombinedintomoreandmore

TheTargetMachine(Mn)
MLayern-1...MLayer2MLayer1TheBaseMachine(M0)

Figure2.13:Layeredvirtualmachinedesign

Thisoperatingapproachsystemwas[61].proposedTheOSbyitselfDijkstraconsisted[62,63],ofwhosixusedlayersitto(processdesigntheTscheduler.H.E.,

48Chapter2OperatingSystemConceptsandApplicationIssues

segmentcontroller,messagecontroller,peripheralcontrollers,userprogramsand
finallytheoperatorwasalsoconsideredaseparatelayer).
Thebenefitsofthisdesignapproachare:
•Eachlayerbecomeseasiertoimplementbecauseitcantakeadvantageofthe
facilitiesandabstractionsprovidedbythepreviouslayers.
•Theresultingsystemiseasiertounderstand,sincetheinteractionbetween
thedifferentpartsofthesystemisgreatlyreduced,especiallythatthede-
unidirectional.islayersbetweenpendency•Testingthesystemcanbedoneincrementally,startingfromtheinnermost
layerandprogressingtowardsthetargetmachine.Ifanerrorisdiscovered
thenthesourceoftheerrorislikelyinthelayercurrentlybeingtested.
Ifthismethodisappliedstrictly(everylayermayonlyusethenextlowerlayer)
toprogramsstructuredintosubroutines,thensoonerorlaterproblemsareen-
counteredbecausetheapplicationdesignoftenrequiresnon-layeredinteractions
betweenfunctions.Theonlysolutionwiththisapproachistoputallthesefunc-
tionsinasinglelayer,causedbythepressuretoreducethenumberoflayers.The
approachcanbeusedwithafairlylargenumberoflayers(PSOS[204,205],the
ProvablySecureOperatingSystem,wheretheOSaloneconsistsof17layers),but
itisnotgenerallyfeasible.Thelayeredapproachistoolimitedformanysystems.
Asareaction,otherdesignerstriedtoimposeatreestructureonthesoftware
structure.Thiseliminatesmanyrestrictionsthatmakesthelayeredapproachcum-
bersome,e.g.thedecisionwhetheraparticularlayermayusealllowerlayersor
onlythelayerimmediatelybelowitself.
Limitingsoftwarestructurestoastricthierarchyisatafirstglancemoreflexible
thansimplelayeredsystems.Layeringisaspecialcaseofahierarchy.Buthierarch-
icalsystemsstillhaveastructuralproblem:commonsubroutinelibrariesusedby
allpartsofthesystemcannotbeadequatelyrepresented,asthiswouldresultina
generalgraphstructure.Parnas[218]criticisedtheomnipresent(positive)useof
hierarchicaldescriptionanditsuseasacure-allsoftwarestructure.
Alsoonecandrawmanydifferenthierarchicaldiagramsofasoftwaresystem,
dependingonwhataspectofasoftwaresystemshouldberepresented.Onecan
drawacomponenthierarchy,aninteractionhierarchy,andafunctiondependency
hierarchy,justtomentionafew.Thesediagramsarepotentiallyverydifferent
intheirstructureevenforthesamesoftwaresystem.Hierarchicalstructuresin
softwaresystemsarenotwelldefined(justaswithlayeredsystems),e.g.sometimes
itisusefultoallownon-hierarchicalelementsordifferentdepths.
BrinchHansen[33]proposedasystemdesignthatallowsseveraloperatingsys-
temstoberunonasingleprocessor,inahierarchicalfashion.Resourcesareal-
locatedalsoinahierarchy.Nestedprocessescanonlygetasubsetoftheresources
oftheparent.Thissimplifiesthescheduler,butisnotflexibleenoughtoadaptto
heavilychangingworkloads.Thisnestedschedulingapproachhasbeenrecently
revived[86,87],withoutsolvingtheproblemsofnestedscheduling.

2.8Structuring

49

Abstraction2.8.2Atrateveryonthepowerfulimportantwaytopropertiesincreaseofthetheflexibilityobjectsofthataneedsoftwaretobesystemisrepresented.toconcen-This
information-hidingaspectsimplifiesthedependenciesbetweensoftwareunits.Ab-
arystractfunctions.interfacesThisfocuskindonoftheabstractionrelevantisverypropertiesusefulandinthepreserveOScontext,variationsinwhereauxili-e.g.
peripheralsareavailableincountlessvariationswithslightlydifferentproperties.
Itbecausewouldabeslightlyalargernightmarediscifiseveryinstalledapplicationinthewouldsystem.haveThistodoesbenotmodifiedmeanjustof
coursethateverythinghastobemadeuniform,itmeansthatonlyasfewpiecesof
systemsoftwareasshouldpossibleusetheshouldabstractneedtointerfaceknowtoathecertaindetails.resource.Theremainingpartsofthe
ferentTheretheisnointerfacesgeneralforruleclassesfortheshouldselectionbe.Tofreatingabstractresourcesclasses,(e.g.definingdiscs,howtapes,dif-
handprinterse.g.oradiscpointingandadevices)pointingdeviceuniformlyshouldreducesprobablysystemhaveacomplexitydifferent.Ontheinterface.other

StructureSystemClient-Server2.8.3Thiseratingisbyfarsystems).themostTheideapopularissimple:structureaforclientofapplicationsaservice(andsendsincreasinglymessagesfortoop-a
servermodel).Thisprovidingthismessage-passingserviceandmodelgetsassumessuitablethatrepliesobjects(followingcapabletheofout-ofreceiving-processmes-
sagesThisaremodelactiveistheentities,basisi.e.ofthatmanysomethreaddistributedisexecutingapplicationinthem.frameworkssuchas
keepCORBAtheornumberDCEofRPC.threadsOftenthewithintheframeworksystemlimitoptimisesandthetoavoidcreationofefficiencythreadsprob-to
lemsoftheCPUscheduler.ManyCPUschedulerimplementationsshowdegraded
performanceevenifmostthreadsareinactive.
Aswithallmessagebasedapproaches,threadswitchesoccurveryfrequently.
Sendingamessageusuallyunblocksawaitingthread,andevenifthisdoesnot
causeanimmediatethreadswitch,thesendingclientthreadthenusuallywaits
foraresponsefromtheserver,whichforcesathreadswitch.Thiseasilybecomesa
theperformanceansweringissue,timeforespeciallyclientsifbytheusingserverusesconcurrentmultithreadingprocessingofexplicitlyseveraltorequests.decrease
ofDebuggingconcurrency.complexSmallerrorsclient-serverwithsynchronisationapplicationsisorveryotherhardduetemporaltothisaspectshighoflevelthe
oneofapplicationtheleadreasonstowhy“sporadic”theGNUerrorsHurdwhich[39]areOSalmost(startedinimpossible1990,toaftertrace.CMUThispub-is
lishedMachwithacceptablelicensingconditions)turnedouttobeexceptionally
hardtodesignandtest.OneofthedesignpropertiesofGNUHurdisthesweep-
inguseofmultithreadingtoavoidprocessingbottlenecksresultingfromsuccessive
.sequentiallyexecutedbeingrequests

50Chapter2OperatingSystemConceptsandApplicationIssues

atesforClient-serverinclusionintoapplicationhighlevelstructureslanguagesare(thefromAdatime[15]totimerendezvoussuggestedasmechanismcandid-is
thebutprimenevergainedexample,widebutotheracceptance.languagesSeveralsuchasprogrammingActiveC[67]languageshavebeensupportproposed),multi-
Vthreadingarious(e.g.microkernelJava[97]),systemsbuthaveusuallyonlyproblemsexplicitlywith.theirmessagepassingimple-
mentation,whichgivesapplicationstheopportunityforadenial-of-serviceattack.
Thisparticularcomeskernel,fromthewhichdetailsoftenofhavethemessagearbitrarypassinglimitationssemantics(see[260]).implementedinthe

StructureSystemModule-Based2.8.4asTheinthealternativein-processapproachmodel.toTheclient-serverobjects(calledsystemsismodulestofocusinonthiscontext,synchronoustoindicateactivity
therelationshiptoinformation-hidingmodules[215,216])arepassive.
Themodulesareexecutedbyprocesseswhichoftendirectlyrepresentusers.
thereSeveralareprocessestypicallymaylessbeprocessconcurrentlyswitchesactivethaninwithinonemessage-passingmodule.Thedesigns.benefitThisisthatalso
simplifiesaccountingandavoidscostlyprocesscreationanddeletionoperations.
doIfso.aItcertaincanusuallyapplicationcreatewantsthreadstoonimplementdemand,aandclient-serverimplementsystem,itsownitisfreemessageto
handlingsystem.Theinterfaceforsuchanapplication-providedmessagingsystem
maybetailoredtospecificneedsoftheapplication,providinge.g.bufferingand
reliableindividualgroupapplicationscommunication.isnotgenerallyThisdegreeavailableofwithcontrolkerneloverleveldetailsimplementations.relevantfor
Module-basedsystemsdefinetheaddressingenvironmentofamodulecurrently
executedbyaprocessmainlyintermsoftheactivemodule.Modulesshouldbe
ciple.strictlyThereforeseparatedfromassociatingeachtheother,addressasspacedemandedwithbythetheprocessinformation-hidingexecutingthemod-prin-
uleingisnotenvironmentideal,asandasingleprotectionprocessdomainmaymustswitchalwaysbetweenbemodules,adjustedandproperlythe.address-
differentThistask,differencecomparedrelatestowiththethein-processconventionalapproach,out-ofwhere-processprocessesapproach.fulfilaslightly
softwareUsingastructuremodule-basedforallsystemsoftwareindesignthehassystem.theModulesadvantagecanthatbeittheallowsafoundationuniformfor
protection,basedonthepermissiontocallindividualsemanticinterfacemethods.

2.8.5OperatingSystem–KernelBoundary
Conventionally,operatingsystemsareimplementedintwoparts,thekerneland
asetofutilities.Onlythekernelrunsintheprivilegedmode,availableinmany
processorarchitectures,whichgivesfullaccesstoallprocessorfeatures.There-
mainingOSfunctionalityisimplementedinmoreorlessstandarduser-levelcode.

Structuring2.8

51

DesigninganappropriateinterfacetotheOSkernelisnotjustaquestionof
providinganinterfacetoapplications,italsoplaysapivotalroleinboththeoverall
systemefficiencyandinthestructuringoftheOSkernelandtheapplications.
Untiltheearly1980stheOSkernelssoakedupfunctionalitylikeasponge.Al-
mosteverypieceofcodethatmorethanoneuserneededendedupinthekernel—
partlyforconvenience,partlyforefficiencyreasons.Theinterfaceprovidedto
applicationprogramshoweverneededtobesimple,whichsometimesmeantthat
acomplexsequenceofcallswasrequiredtoachieveacertainfunctionality.The
resultwasalarge,complexOSkernelwithaninterfacethatleftalottobede-
sired(eventhestillrelativelysimpleUNIXkernelwasnotimmunetobloatedand
inappropriateinterfaces,seethesundryfunctionalityundertheioctlinterface).
Applicationsalsohadtouseaninterfacethatwasnotquitewhattheyneeded.
Anotherproblemisthesecurityoflargekernels.Toprovethesecurityofan
OS,thefirststepistoverifytheOSkernel.Thisisimpossibleifthekernelcode
exceedsacertaincodesize(Linux2.4.26hasmorethan3.3millionlinesofC
code,determinedwiththeSLOCCounttool[299]).Tomakethingsworse,the
codecomesfromavarietyofauthorsandsuppliers(frequentlydevicedriversare
writtenbythedesignerofthehardware),andusesallsortsofprogrammingtricks.
Buttheintractabilityofverificationisjustoneaspect,themoreimportantoneis
thatasmallerrorinanypartofthekernel(suchasinabadlyimplementeddevice
driver)cancompromisethesecurityofthewholesystem.Allofthekernelruns
inprivilegedmode(sometimescalledsupervisormode)oftheprocessor,giving
fullaccesstomemoryandI/O.Everypartofthekernelcanpotentiallyoverwrite
(erroneouslyormaliciously)thestateofthekernel—changingtheaccessrightsof
acertainprocessorjustproducingahardtotracesystemcrash.
Thissupportstheargumentforputtingthedevicedriversoutsidethekernel12.
Monolithickernelsaredelicate“animals”,whichmeansthatiftheirsizebecomes
“toolarge”(thereisnoprecisefigure,itdependsonmanyfactorsincludingthe
readabilityandgeneraldesignofthecode),boththenumberofknown(butnot
easilyfixable)andunknownerrorsstarttoincreasenon-linearly.Asaresultit
becomesinaccessibletocurrentsoftwareengineeringpracticessuchasrefactoring.
Onlyawell-understoodsoftwareunitcanberefactored,aspotentiallymanyother
piecesofcodedependingonithavetobeupdatedaccordingly.
Havingalotoffunctionalityrunninginprivilegedmodeincreasesperformance,
butalsodecreasesflexibility.Thekernelitselfusuallyismuchmorerestrictedin
whatitcancallthanapplications,becausethereisnolinkingprotocoltouser-level
librariesandapplications.Howeverthecurrenthardwaretrendistotunnelevery
hardwareaccessprotocolthroughalmostanyotherprotocolavailable.Thenew-
estandmostgeneralapproachistotunneleverythingthroughaTCP/IPnetwork
connection(e.g.iSCSI[245]definesanetworkprotocoltransportlayerforSCSI
deviceaccesses).Thiscomplexityoflayersisveryhardtohandlewithinthekernel

12drivers,WhichbutiswhstillatcreatNooksinga[272]separationtriestostrongachieveforenoughLinux,tocatchwithouterrortrulysorsepmaliciousaratingkernelkernelandmodules.device

52Chapter2OperatingSystemConceptsandApplicationIssues

itself,andfrequentlyrequiresalotofduplicatedcodebecausethelayeredprotocol
designcannotberepresentedproperly.Evenifitcouldbehandled—whyshould
it?Doingitoutsidethekernelwithproperflexiblesoftwarestructuresremovesa
lotofthearbitrarycomplexitythatcomeswithakernel-modeimplementation.
Kernelstypicallyhavenoaccesstouser-levellibraries,whichencouragescode
duplication.Theduplicationoccursusuallyin“slightlymodified”sourcecodeform,
magnifyingtheriskoferrorsandtheworkneededtofixthem.Anexampleisthe
ONCRPCcodeintheLinuxkernel(usedtoimplementthenetworkfilesystem
NFS).Itssourcecodewasmodifiedsubstantiallywhenitwasincludedinthekernel.
Overthelasttwoyearsanumberofcriticalerrorswerefound.FixingtheLinux
kernelversionwasnottrivial,sincethecodewasnotidenticalanymore.
ProvidingaflexibleOSstructureishardforsystemswherethekernelmonopol-
isesallfunctionality.Applicationsoftencannotassumeresponsibilityoveranything
thekernelprovides,simplybecausethereisnointerfaceforit.Thisattitudestillex-
istswiththemicrokernelapproach,whichdelegatesalmosteverythingtothe“user
mode”.HowevertheOSrunningontopofthekernelagainkeepsthesepowers,
andtheapplicationsgetatraditionalOSsysteminterfaceonly.Itisdefinitelysim-
plertomaintainprotectionthisway,butthiscomesatahighprice:inefficiency.
Moreefficientuseoftheavailableresourcesinevitablyrequiresthattheapplic-
ationsmustgetmorecontrol.Findingasolutionthatstillallowsasecuresystem
andthatdoesnotforceeveryprogrammertodealwithlow-leveldetailsisthegoal.

InterfacesUserGraphical2.8.6Fromthebeginningthepresentationofuserinterfaceswaspartoftheapplication,
butthisviewhaschangedstartinginthemid-1980s(whentheresultsoftheXerox
PARCprojects[281]foundtheirwayintocommercialsystems).Userinterfaces
becamestandardised,separatepiecesofsoftware.Someimplementationsonly
provideagraphicaluserinterfacelibrary,whileothersmadeitpartoftheOSkernel
andcorrespondinglytheamountofkernelcodewasgreatlyincreased.
Allthesedevelopmentshavestructuralimplicationsthatgofarbeyondthescope
ofanindividualapplication.Initiallythetextualinterfaceshadaverysimpleshar-
ingconcept,wherebasicallythecurrentlyrunningapplicationhadthesolecontrol
overthedisplaycontent.Consequentlytheycaneasilybeincludedinasingle
program.Graphicaluserinterfaceshavesophisticatedsharingandcooperation
semantics,managingthedrawingofoverlappingwindowsfromdifferentapplica-
tions.Thisinvolvescommunicationbetweentheapplications(andtypicallyacent-
ralwindowmanager),whichnecessitatesamoreflexibleinputprocessingmodel.
Graphicaluserinterfacesgenerallyassumeanevent-basedprocessingmodel(one
couldalsorefertoitasmessage-passing,butintheGUIcontexttheeventnotionis
morecommon).Thisforcesatotallynewstructureontheapplications,becausethe
traditionalapproachwhichjustoccasionallyacceptsinput,separatedbypotentially
longcomputations,wouldmakethepropersharingsemanticsimpossible.Thisis

Structuring2.8

53

anconsequencesexamplewhereontheaseeminglystructureoftheunimportantwholestructureimplementationofthedetailapplication.hasfar-reaching
Ittookafairlylongtimetotraintheprogrammerstothisnew“paradigm”,but
nowInitiallyitiseverygenerallyprogramacceptedhadtoandbetheredesignedqualityoftothefitintoapplicationstheeventisacceptableframework,again.and
thepieces.Thislong-runningtotallyalgorithmsdestroyedthehavebeenapplicationslicedlogic,upintoandcreated(hopefully)adesireshorttogetenoughrid
ofthe“manualscheduling”doneintheapplicationdesign.
theTodaymain,applicationlong-runningpartscontrolsareandoffif-loadednecessaryintoaabortsseparatethisthreadthread.ofThisexecution,solvesandthe
duplicatedworkwithscheduling,butintroducesanewproblemthatfewapplica-
tionapplicationsprogrammersneedtohavesynchroniseconsciouslyaccessesdealttowithsoglobalfar:stateconcurrencyinformation,.andMultithreadedlikeall
mistakesproblemsishigh.involvingThisisconcurrentexacerbatedoperationsbymovingthepartsprobabilityoftheofGUImakingintothehard-to-findkernel.

LibrariesCode2.8.7Inareal-worldsystemmanypiecesofcodecomefromstandardcodelibraries,
e.g.maintainedprovidesaseparatelyconvenientfromtheinterfaceOS.toThekernelcodeisfunctions.oftenTheheavilysheerOSnumberdependentofandap-
plicationsdependingonthesestandardlibraries(typicallyeveryprogramforapar-
ticularsystem)placesuniquedemandsonitsefficiencyandmaintenance.
Suchlibrariesarecurrentlythemostcommonlyusedandmostsuccessfulform
ofbeencodeprovidedreuseoninathislargeform,scale.sothereisHoweveralot,onlymoregeneralpotentialforpurposereuse,functionalitywhichinturnhas
promisestodecreasesoftwaredevelopmentcostandtoincreasereliability.
Likeanyothersubstantialpieceofsoftwareitcontainserrorswhicharecorrected
fromtimetotime.Itwouldbeconvenientifreplacingjustthelibrarywouldsuffice
toanddoincludenotthecopyfixtheinalllibraryprogramsintoeveryusingtheprogram,librarybut.Mostimplementsystemsdynamictodaysupportlinkingandthis
keeplibrariesasseparatefilesinthesystem.Thiswaytheycanbeeasilyreplaced
andthefixedcodebecomesactivewhentheprogramsarerestarted.
Sharinglibrariesalsohelpswithefficiency,sincecode(beingread-onlyinmost
cases)physicalcanbememory.sharedOntheeasily,othereliminatinghand,sharingredundantofcodecopies(inofconjuctionthesamewithcodesoftwarefrom
notupdates)fullycancompatibleleadtowithseverethepreviousmaintenanceversion.nightmaresThereifise.g.noanewparticularlibraryreasonversionforit,is
butthisversioningproblemoccursmorefrequentlywithMicrosoftWindowsthan
withUNIX.ItiscommonthatapplicationsforWindowsusetheirprivatecopyof
standardlibraries,butthisobviouslynullifiesalltheadvantagesofsharing.
Becausesharedlibrariesaresouseful,theydeservespecialOSsupporttomake
theiruseassimple,efficientandsecureaspossible.

54Chapter2OperatingSystemConceptsandApplicationIssues

Summary2.9

Thischaptercontainsanoverviewofthefunctionalitycommonlyconsideredthe
dutyofanOS.ThefunctionalityofanOS,viewedfromanabstractperspective,
istoprovideanadequatevirtualmachineforthevariousapplicationthatarerun-
ningonacomputersystem.Therawhardwaredetailsareirrelevantforalmost
allapplications.Thiscodereuseaspectandtheresourcesharingbetweenegoistic
applicationsjustifytheexistenceofoperatingsystems.
WhileeveryOSneedstoaddressthesefunctionalityrequirements,itdoesnot
meanthatthevariousOSimplementationsagreeonthemechanismsandstructur-
ingtoachievethis.Thisillustratesthedifficultyofdevisingan“ideal”OS.Alloper-
atingsystemsthatarebasedonadeliberatedesign(andnotsimplyonanad-hoc,
demand-drivencollectionoffunctions)aregenerallyperceivedbytheirdesigners
tobeideal.Thisistobeexpected,asitisthenormtousethedesignphilosophy
asameasure.Thishighlightsthatthereisnoagreed,objectivemetricformeas-
uringtheidealnessofanOS.Thedesignphilosophy(whichisofteninfluencedby
softwareengineeringstandards)predeterminesthestructureofanOS.
AconsequencefromthelackofmetricsisthatmanyOSdesignphilosophies
containalargelistofproblemstoavoidinsteadofdefiningtheaims.Thisreflects
theexperimentalcharacterofOSdesign,andeachOStriestobeoptimal.The
experiencewiththeOStells(subjectively)whetherthataimwassuccessful.
Sowhatcanbelearntfromthischapterwithitslargecollectionoftopicstoad-
dress?Mostofthevariantsarerequiredand/orconvenientincertainapplications.
HoweveraddressingthemallappropriatelyinasingleOSdesignisaHerculean
task.Thusthefocusshouldnotbeoncateringforallvariants,butonproviding
abaseimplementationthatisflexibleandextensible,capabletosupportarbitrary
applications.bydemandedasvariationsFlexibilityandextensibilityplayonlyasecondaryroleinmanyOSdesigns,as
wewillseeinchapter3.Thefirstsystemsthatformulatedtheserequirementsas
designprinciplesareHYDRA[306,172]andSolo[34].Bothsystemsarequite
oldandhavethereforebeendesignedwiththescarceresourcesinmind,which
forcedthemtokeepthedesigncleanandsimple.Sincethenmemoryandcomput-
ingpowerhavebecomealmostunbelievablycheap,whichallowedlarge,complex
operatingsystemstobedeveloped,butoftenwithoutfulfillingtheseaims.
GoingbacktotherootsisessentialforanewOSdesignthatstrivesformaximum
flexibilityandextensibilitywithminimumcomplexity,whichistheprimedesign
principleselectedforSPEEDOS.Inchapter3acollectionofoperatingsystemswill
beanalysedindetail,toidentifytheirstrengthsandweaknesses.
Thisofcoursecreatesthetemptationtointroduceindividual,localmodifications
tooneofthesedesignsonly.Thiswouldviolatetheprimedesignprinciple,asthe
designprinciplesofmostoftheanalysedsystemsareincompatible.Atrulyflexible
andextensibleOSisnotjustamodificationofoneofthecurrent,inflexiblesystems,
solutions.newadoptmustbut

3Chapter

SurveyOperatingofSystemMechanismsDesignsinExisting

55

SelectingtheappropriatesystemdesignforanOS(andinconsequencealsofor
proachesapplications)haveisbeennotassuggested.simpleasitEveryseems:nowoverandthethenlasta40newyearsideawashundredsintroducedofap-
ortheaimportantparticularlyoperatinggoodarrangementsystemsorofOS“old”kernelsideasiswasdescribedfound.inAmoresmalldetailselectioninthisof
chapter.Theanalysisisundertakenalongthelinesofchapter2,whichsummarised
themostimportantpropertiesofoperatingsystems.
suffersLearningduetofrom“religiousoldersystemswars”toaroundcreateparticularbettersystemsconcepts.isAlsoimportant,theyetconnectionoften
ThebetweenthefollowingOSsectionsstructureareandarrangedapplicationbythestructuredateisoftendevelopmentneglected.workbeganorby
thefirstpublication(althoughforsomesystemsitishardtofindoutanythingabout
theirearlyhistorybecauseveryfewpublicationsexist).

UNIX3.1

Inthelate1960saprojectwasstartedtodevelopalean,stripped-downversionof
MULresearchersTICSat[212].BellTheLabs,aimwhowastofoundfocusaonlittle-usedthebasicscomputeronly.Itandwasthedecidedworktoofaprogramfew
ausableoperatingsystemforit[233].DennisRitchieexplicitlyrejectedtheurban
ItlegendsoonthatgatheredUNIXastartedsizableasauser“skunkgroup.works”Theprojectoperating[234].systemwasdistributedwith
therequirementssourcecode,ortowhichportitmadetoaitpossibledifferentfortheplatform.ItcustomerturnedtoadaptoutitthattoitsUNIXwasparticularan
idealmanysysteminteractiveforusers,universities.anditIthadprovidedamoderateconsistentresourceinterfacetorequirements,user-levelcouldprogramshandle
acrossvastlydifferentcomputers.Applicationstypicallyonlyhadtoberecompiled.
UNIXUNIXreachedtriggeredafarabetterrevolutionincross-platformcomputing,compatibilitymakingthethanswitchanyawaycompetingfromOS.batch
simplifiedprocessingOStointeractive(comparedtousagemainframes)feasibleonmaderelativelyiteasytocheaplearncomputers.andprogram.Thegreatly

56Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

StructureandHistory3.1.1TheUNIXkerneloriginallywasverysmall:itconsistedofverysimplememory
management(onthePDP-7therewasnovirtualmemory),verysimplescheduling
(aftertheforksystemcallwasimplemented)andasimplefilesystemalongwith
alldevicedrivers.More“advanced”filesystemfeatures(e.g.creatingadirectory)
wereimplementedwithprivilegeduser-levelprograms.
Initiallyitwaswritteninassemblylanguage,butlater(onthePDP-11)itwas
rewrittenintheCprogramminglanguage[156]thathadbeendevelopedinparal-
lelbyBrianKernighanandDennisRitchie.Becauseofthesimplicityofthekernel
andthecompiler,itwasfairlyeasytoportUNIXtoavarietyofmachinesthatwere
popularintheearly1970s.Theuniformsoftwareinterfacetodifferentcomputer
architectureswasveryappealing(abitliketheprocessorfamilyapproachinthe
IBMSystem/360).UNIXbecametheanswertotheburningdesiretoreducethe
workrequiredtoportanapplicationtoadifferentcomputer.
Akeytoitssuccesswasthesmallkernel,complementedbyasetofsmalluser-
levelapplicationstoimplementuserlogin,jobschedulingandothersystemser-
vices.KenThompsondefinedthescopeofUNIXinapaper[282]:
“TheUNIXkernelisanI/Omultiplexermorethanacompleteoperating
system.Thisisasitshouldbe.”
ThischaracterisesthefirstdecadeofUNIXdevelopmentbytheoriginalauthors
KenThompson,DennisRitchieandBrianKernighanandothersatBellLabs.Atthe
endofthatdecadeUNIXbecameacommercialsuccessstoryforAT&T.Ironically
thismarkedthestartofadecline,becauseAT&Tdecidedtostopdistributingthe
sourcecodeundertheprevious,fairlyliberallicensingconditions.Theeffectwas
asplitofUNIXintovarious“flavours”,whichwerederivedfromvariousUNIX
variantsdevelopedatuniversitiesorcomputermanufacturers.Theensuingyears
canbedescribedbestbytheincompatibilities1ofBabylonicextent.
HowcouldUNIXturnintoamonsterinthecourseoflessthanadecade?Some
ofthesupplierswerenotatallinterestedinportability,asthiswouldmeanthat
theircustomerscouldeasilyswitchtoadifferentsupplier.Anotherreasonwasthat
AT&TitselfcontinuedtodevelopUNIX,changingtheinterfacesinincompatible
waysandofferedthenewversionstothesuppliers.Someofthemadoptedthem,
somedidnot,andothersblendedseveralofthem.Theincompatibilitiescontinued
toflourishuntilthemid-1990s,whentheUNIXcompetitorsmanagedtogaina
substantialmarketshare.UNIXwasdeclareddead.Itwasnot,becauseaftersev-
eralstandardisationprojectstheinitialcompatibilityacrossanalmostuncountable
reestablished.wasplatformsofnumber1share.AmuchTheBerkeleyimprovedvariantSoftwarefromDistrithebutionUniversity(BSD)ofremainsCaliforniaoneofattheBerkelemajoryhadvariantsasizablestillavailablemarket
freetoday.fromWhencodeUCBcopyrightedstoppedbyactiveAT&T.Itdevelopment,isthebitasisofreleasedfurthertheNet2developversion,mentinwhichthewasNetBSDcompletelprojecty
(founded1993),fromwhichtheFreeBSD,OpenBSDandDragonFlyprojectsweresplitoffdueto
differentopinionsandinterestsoftheprojectleaders.

UNIX3.1

57

lem.TheItishugeimpossiblenumberoftofeaturespreventaccumulatedprogrammingintoerrorstheinkernelsuchabecamelargeakernel,seriouscreatingprob-
loopholesintheprotectionsystembyunwantedkernelstatemodification.

ManagementProcessandMemory3.1.2TheUNIXkernelimplementsprocessisolationthroughaseparatevirtualmemory
permemoryprocess.pagesThethatdokernelnotusescurrentlyareservedfitintoportionmemoryof.theThediscvirtualtopagememoryoutlosesvirtualits
contentacrossreboots.Consequentlyprocessesdonotsurviveasystemreboot.
veyingTheaddressappropriatespaceofaprotectionprocessissettingstypicallyforcode,structuredconstants,intofourdata/heap“segments”,andstack.con-
Thismemoryis.todayMemoryimplmappedementedfilesbyprovidemappinganportionsalternativeofainterfaceprogramforfileintoaccessingvirtualthe
fileAllcontentmodern(readingUNIXandversionswritingalsoareprovidepossible,multipledependingthreadsonoftheaccessexecutionrights).withina
Csinglelibrary,addresswhichspaceimplements(eitherastheainterfaceuser-leveltoortheUNIXkernel-levelkernel,providesimplementation).manynon-The
thatthread-safeeitheronlyfunctionsasingle(duethreadtoitsusesage).themItoristotheselectaresponsibilitythread-safeofthevariant.programmer
creatingProcessestheareusercreatedenvironmentonuseronlogineveryandloginareisadeletedsubstantial(bycostdefault)factoroninlogout.UNIX.Re-
Everyprocessexecutesundertheidentityofaparticularuserandbelongstoa
setofgroups(thekernelusesnumericuserandgroupidentifiers).Allprocesses
createdbyaparticularprocess(usingtheforksystemcall)inheritthisidentity.
Processesmaydeleteotherprocesses,providedthattheiruseridentifieristhesame.
UNIXgenerallyfollowstheout-of-processmodeltoimplementtheuser-level
partoftheoperatingsystem.Manyoperatingsystemservices(suchastheprinter
spooler)executeinthecontextofthesuperuser.Theactualkernelinterfacehow-
everceeds100followsthefunctions)in-processexecuteinmodeltheandcontextallofsystemthecallscalling(inaprocess.modernUNIXthisex-
whichbyApplicationsconventionaretypicallyhavefewstructuredcommunicationintoveryfewdependenciesprogramsonofothersubstantialprocesses.size,
Theducedbynumberignoringofcentraltheseservicesservicesisisfairlytypicallysmall,negligible.thereforetheaccountingerrorintro-
butItthiswouldwouldbepossibleactuallytobeaimplementdifferentanOS,in-processincompatibleOSwithwithathemodernUNIXUNIXspecification.kernel,

ManagementResource3.1.3ResourcemanagementisoneofthemajorshortcomingsofUNIX.Sincethekernel
managesprocessesifthethevirtualmemorymemoryconsumptioncompletelyofonprocessesitsown,exceedstheonlythechoiceavailableistospace.delete

58Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

TheCPUschedulersupportspriorities,buttheyareautomaticallyincreasedfor
I/O-intensiveprocesses,providinglittlecontroloverwhichprogramsmayrun.
andUNIXonprovidesmemoryaconsumption)mechanismtoanddefineglobalper-processresourcelimitsresource(suchlimitsas(ontheCPUnumbertime
ofprocessesausermaycreate),butthisonlyguardsagainstrunawayprocesses.
Thereisnosuitablefine-grainedcontrolovertheresourcesthatpreventsresource
hogsfrommonopolisingresources,blockingotherprocesses.

3.1.4FileSystemandDeviceDrivers
ThecentralhubofUNIXisthefilesystem,whichstemsfromthedesignphilosophy
area“everythingsequenceisaoffile”.bytesAllwithpersistentnofurtherdataisstoredstructuring.intheThisfilesimplesystem.interfaceFilesinisUNIXthe
leastcommondenominatorofwhatotheroperatingsystemsprovidedwhenUNIX
wasconceptindesigned.theSincekernel,UNIXmoreintendedcomplextostorageimplementstructuresonlytheweresimplestlefttothevariantofapplicationevery
programsthatneededthem(e.g.databasemanagementsystems).
Thesimplefileinterfacewasalsousedasanopportunityforabstraction:device
driversinterface.andmanyIncludingthecommunicationdevicedriversmechanismsasobjectsuseinthethesamefile(orsystemslightlymakesenhanced)them
subjectprocessestoifthetheprotectionsuperuserhassystem,setupwhichtheaccessallowsrightsdirectaccessappropriatelyfrom.non-privileged

MechanismsProtection3.1.5Everyobjectinthefilesystemhasanowner,whichisthecreatorofthefile(unless
changedafterwardsbythesuperuser).Everyobjectisalsoassignedtoagroup.
Theaccessrightstoeveryfilearespecifiedasbasicaccessrights(read,writeand
execute)foreachtheowner,thegroupandallotherusers.Thisimplementsavery
restrictedformofanaccesscontrollist.ThestrictstructuringoftheACLprevents
implementingarbitraryfileprotection,whichisfurtherexacerbatedbecauseman-
aginggroupsisthesoleresponsibilityofthesuperuser,preventingefficientgroup
management.ModernUNIXversionsimplementarbitraryACLs(notlimitedto
owner,groupandworld,withthesameaccessrights),buttheutilitiestomanage
themareclumsytouse.Generallytheyarenotwidelyused.
Thereareafewancillary“accessrights”thatexpressspecificpropertiesofpro-
grams.ThesetuserIDbitspecifiesthataprogramshallexecutewiththeuserIDof
thefileowner.Thisisthebasisforimplementingprivilegedprograms,whichrun
withthesuperuserIDandthereforehaveunrestrictedaccesstothekernelopera-
tions.AfurthersetgroupIDbitspecifiesthataprogramshallrunwiththegroupID
ofthefile,whichenforcesthatfilesonlyaccessiblebythatgroupbecomeaccess-
ible(andallfilescreatedbytheprogramalsobelongtothisgroup).Thesespecial
accessrightsmayonlybesetbythesuperuserandtheownerofthefile.

UNIX3.1

59

Thebyte-orientedinterfacetofilesincombinationwiththecoarse-grainedaccess
rightsshouldonlymakesbeitallowedimpossibletotoreadcontroland/oraccessmodifytohisspecificownpartsdata).oftheThisfilecreates(e.g.apres-user
suretoseparateinformationintomanyfiles,withmatchingaccessrights,owner
andternativelygroupthesettings.accessThiscontrolusuallysystemcanisonlybedelegatedsetuptothewithapplicationsuperusersystemprivileges.(e.g.Al-a
Thedatabasegeneralmanagementobjectbrowsingsystem),problemwhichisinanhopefullyACL-basedsystemnon-circumventable.isreducedinUNIX.
thenObjectthebrowsingcontentrequiresbecomesreadinvisible.accesstoOpeningthefilesdirectoryand.Ifrunningthisaccessprogramsrightinissuchunset,a
directoryisstillpossible,providedtheexecuteaccessrightisset.
malTheuserssuperusermaynot(withaccesstheforUID0)securitymayusereasonsthe(e.g.privilegedterminatingkernelarbitraryfunctionsthatprocesses).nor-
runsManywithattacksUIDto0,aUNIXgainingsystemcompletethereforecontrolstartoverasantheattacksystem.againstHavingaaprogramuserwiththat
unlimited(andunlimitable)accessrightsisasecurityhazard.

Authentication3.1.6program.AuthenticationItrunsiswithpurelyasuperuseruser-levelprivilegesservice,andmayperformedthereforeinthecreatecontexttheofuser’stheloginpro-
cessandchangetheuseridentifierandthesetofgroupsitbelongstoappropriately.
Thatinitialprocessistypicallyashell.
Allauthenticationdata(includingtheencryptedpassword)wasinitiallystored
aintheseparatepasswdfiletofile,whichwhichonlyeverytheusersuperusercouldread.(andtheThereforepasswordtheislogintodayprogramstoredandin
isanystillotheravailableprogramtoeverywithuser,superusergivingrights)hintsonhaswhichaccess.accountsThelistareofvalidworthusercracking.names
Theauthenticationalgorithmiscentrallydetermined,usuallybasedonpassword
ethelessverification.itisSomealwaysthesystemssamemakeforalltheusers.authenticationalgorithmconfigurable,non-

SynchronisationandCommunication3.1.7OvertheyearsUNIXaccumulatedanimpressiverangeofcommunicationandsyn-
chronisationschemes(besidesusingfiles).Themechanismswerefittedtothe
kernelinmoreorlessconsistentways(mostlyintothefilesystemcode):
pipes:Themostfrequentlyused(andoldest)communicationvariant.Apipeis
aunidirectionalcommunicationlink,initiallybetweentwofiledescriptors
withinoneprocess.Byusingforkandexectheconnectioncanbepassed
ontoseparatechildprocessesthatmayuseittotransferastreamofbytes.
namedpipes:Aconceptrelatedtopipes,butitdoesnothavetobesetupbya
commonparentprocess,becauseitexistsasavisibleobjectinthefilesystem.

60Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

signals:ities.AnItisusedinterrupt-likebytheconstructkerneltothate.g.providessignalarithmeticnegligibledataoverflowtransferoraccesspossibil-to
anconveyinvalideventmemoryindications.location.Signalscanalsobesentbyotherprocessesto
sockets:DifferentAsocketiscommunicationanabstractiongranularitiesthatcanarerepresentsupported,networksuchasdatagrams,communication.se-
quencedpacketexchangeorbytestreams.
sharedbetweenmemory:separateThereareprocesses.anumberSomeofmethodsrequiretosetassociatingupathesharedsharedmemorymemoryblock
someblockwithmanipulateafile,onlywhichthethenreflects(non-persistent)allchangesvirtualtothememory.sharedmemory,and
semaphores:processeswithoutSemaphoresbusyprovidewaiting,aformeansusetowithcontrolsharedthememoryconcurrent.executionof
TheThisside-effectarrayofisthatmechanismsallisnetworktraditionallycommunicationcompletelyprotocolsimplementedwerealsointheforcedkernel.into
thekernel.Thisgreatlyincreasedthesizeofthekernelandintroducedamajor
securityhazard:ifthenetworkprotocolsareincorrectlyimplementedthenthe
kernelprotocolsstatewerecanbediscovered,modified.whichOvercouldthelastcausedecade,systemseveralcrashessuchorerrorsallowedinarbitrarynetwork
codeManytobeUNIXinjectedprogramsintotheassumekernel.thattheyreceiveastreamofbytesthroughthe
(thestandardinputcommand-line“file”andinterpreter)generateasupportsstreamofchainingbytesonprogramstandardexecutionoutput.byTherunningshell
themout-ofin-processconcurrentmodelusedprocessesforandUNIXsettinguser-leveluppipesprograms.betweenProcessesthem.Thisarecreatedreflectsandthe
deletedfrequently,whichdecreasesefficiency.Yetthenumberofprocessesdoesnot
mushroom,astheexecutionofapipeisstillfairlysequential.
ate,Thisislong-runningtotallydifferentprocessesin(intheUNIXcontextcalledofthedaemoncentral).Theservicesprinterprovidedspoolerbyandsepar-the
agraphicaldifferentuseruserandinterfaceexposesystemmoreof[208,the206,out-of207]-processintroducedrawbacks.servicesAlsothatinaretherunmid-by
more1990sandnetworkmorepopularcommunication.usingRPC[269]orsimilarmiddlewarebecame

SummaryandDiscussionCritical3.1.8Thegrandfatherandmodelofmanyoperatingsystemsisstillpopularmorethan
30yearsafteritsdesign.Overtheyearsithasbeenextendedandenhancedtokeep
upwiththetechnicaldevelopment(e.g.toincludesupportfornetworkcommunic-
ation).Despiteitsconceptualweaknesses,thesimplicity,usabilityandpopularity
ofUNIXsurpassesthatofMULTICS.

UNIX3.1

61

ThestructureoftheUNIXkernelbecameaprobleminthe1980s,butonlybe-
causeitsdesignerslostsightoftheprimeaim,namelytoprovideasimplekernel.
FeaturismwasdeemedmoreimportantthanadjustingthestructureoftheOSto
maintainthedesignphilosophy.Ironicallythisproblemwasalsopresentinthe
MULTICSimplementation,sothislessonwasnotyetlearnt.
UNIXisanOSthathasprovenitsusefulnessinalargenumberofinstallations,
butithascertainstructuraldeficienciesthatlimitsitsrange:
a)Thelargenumberofdifferentfilesystemimplementations,devicedrivers
andcommunicationmechanismsaccumulatetoanenormouskernel,with
theaccompanyingriskoferrorsinfullyprivilegedcode.
b)Nomechanismtodelegatenon-essentialkernelfunctionalitytouser-level
code.c)Simplisticfileaccessrightssystemthatishardtomanageinasecurefashion,
i.e.accordingtotheprincipleofleastprivilege.SUIDprogramscanleadto
protectionevasion,astheyrunwithadifferentidentity.
d)Applicationprogrammersneedtospendasubstantialefforttomaketheres-
ultsofprogramspersistent,bystoringtheminunstructuredfiles.
e)NoadequateresourcemanagementtocontrolmemoryorCPUusage.
f)ManyOSservicesrunwithsuperuserprivileges.Someofthemhaveawell-
documentedhistoryofremotelyexploitableerrors.
g)Acentralusertableaccessibletoeveryuser,andacentrallyimplemented
authenticationmechanismmakeiteasytobreakintothesystem.
UNIXis(andwillremain)popularforsystemswhichrequireonlymoderatese-
curitymeasures2.Itsresourceefficiencyisgood,butitsuffersfromthelackofa
suitableOSstructurethatcandelegatethedutiesofthekernelwhicharenotes-
sential.Thiswasattemptedinthemicrokernelapproach(seesection3.6),butwas
notverysuccessfulinitially.Delegationisexpensiveinanout-of-processOS,since
thecostofaprocessswitchisaddedtothecostofasystemcall.
AT&TBellLabscontinuedwithOSresearch,independentlyofbutinspiredby
UNIX.SomeoftheUNIXdevelopersareactiveinthefollow-upprojects.First
Plan9[219,47]attemptedtoimprovetheapplicationstructureandmakethe
wholesystemmoremodular,thenInferno[65,223],whichisanattempttopro-
ducealightweightOSfordistributedservices.ThelatestprojectisPebble[95,38],
acomponent-basedoperatingsystemdesign.Itsmainaimistosolvethestructur-
ingproblemswithlargesoftwaresystems.Allprojectshaveproducedsystemswith
asubstantialuserbaseintheindustry,butnoneofthemisnearlyaspopularas
UNIX,despitetheirconsiderableimprovementsoverUNIX.
XP2Howevertheoreticallyitisstillhasamoremoresecuresecurethandesign,e.g.butstandardthishasbeeninstallationsfoiledofbytheMicrosoftusWer-levelindowspartsXP.ofWtheindowsOS,
wherethedeveloperspreferredeaseofusewhereveritwasinconflictwithsecurity.

62Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

OSeyKK3.2

AnMULearlyTICSisattemptKeyKatOSa[98],capability-basedinitiallyforIBMoperatingSystem/370systemwithamainframes.philosophyDevelopmentsimilarto
startedwidenedintoa1975asageneral-purposespecial-purposeOSunderOSthecallednameGnosisKeyK[93]OS.Itsandaimslaterwerethetoscopeprovidewas
aThesecureinitialcomputingapplicationenvironment,wasparthighofBritishreliabilityTelecom’sandTaccurateymnetservice,accounting.andcon-
sequentlytheaimsarerelatedtotheparticularrequirementsforacomputerfacil-
ityininformationthiscontext.andTheresources.usersdoSoftwarenotnecessarilyupgradesthattrusteachshouldother,improveyetthehavetofunction-share
alityreworkedofasystemtelecommunicationstructureshouldsystemhelpfrequentlyovercomingcausedthisareliabilitysystemcrash.problem.Aradically
ventedImportantotherpartsoperatingofKeyKsystemsOSarefromcoveredfollowingbyathepatentKeyK[99],OSdesignwhichuntileffectivelythepatentpre-
PCexpired.hardwareRecentlywasastartednewbyattemptJonathanatS.implementingShapiro,atheformermainconceptsmemberofontheKcommodityeyKOS
team,withthenameEROS[258,256].EROShasaslightlydifferentprotection
themechanismconfinementthanKeyKproblemOS,for[257,which259]aexists.formalproofofcorrectnessforitssolutionto

Structure3.2.1KeyKOSconsistsofakernelthatimplementsvirtualmemory,processes,thepro-
tectionsystemandlow-leveldevicedrivers.ThedesignersofKeyKOSrefertotheir
kernelasa“nanokernelarchitecture”[30],butprovidenoconvincingdistinction
toamicrokernelarchitecture(especially“nano”doesnotseemtorefertoasmaller
sizethan“micro”,sincetheKeyKOSkernelneedsaround100Kbytemainmemory).
Thekernelisstateless,whichmeansthatitonlykeepscachedinformationfrom
theauthoritativesourceinpersistentvirtualmemory.Thisgivesthekernelthe
freedomtorepresentdatainternallyinamoreefficientway.Thecontentofthe
cachemaybediscardedatanytimeandreconstructedfromthepersistentdata.
Applicationsareimplementedasacollectionofservices,eachwithanassociated
serverprocess.CommunicationbetweenservicesworksthroughRPCs.
Devicedriversareseparatedintotwoparts.Thehardwareabstractionlayerthat
providesanabstract,message-orientedinterfaceispartofthekernel.Theupper-
levelpartofadevicedriverisimplementedasauser-levelobjectinKeyKOS,with
itsownprocesstoprocessthemessages.
Severaloperatingsystememulationsareprovidedasauser-levelservice,suchas
VM/370,asubsetofMVSandasubsetofUNIX(andKeyKOShasbeenportedto
otherprocessorarchitectureswithonlysmallmodifications).TheprovisionofOS
emulationsisfacilitatedbytherigidapproachtoprotection.Completeisolationis
thedefault,andonlythepossessionofcapabilitiesgiveaccesstoanything.

OSeyKK3.2

63

ManagementProcessandMemory3.2.2EverythinginaKeyKOSsystemisstoredinapersistentvirtualmemory.Thekernel
manageswhichpagesarepresentinmainmemoryandalsoguaranteespersistence
ofdatabycreatingperiodicsystem-widecheckpoints.AllprocessesandI/Oactivit-
iesaresuspendedandalldirtypagesaretransferredtothecurrentcheckpointarea
ondisk.Thenthealternatecheckpointareaismadecurrentandtheprocessesare
resumed.Checkpointoperationsarenotallowedtooverlap,guaranteeingthata
consistentsystemstateisalwaysavailableinthepersistentstore.
Havingastatelesskernelavoidsthecomplexityofhavingtocheckpointtheker-
nelitself.Systemcrashesappeartotheapplicationsasjumpsintherealtimeclock
only.Thecheckpointingguaranteesthatallprocessesanddataareinaconsistent
stateinthepersistentstore,sothatexecutioncanresumeasifthecomputation
betweenthelastcheckpointandthecrashneverhappened.
Thestackandotherdatastructuresdescribingaprocessarealsostoredinvirtual
memoryandaresubjecttocheckpointing.Togetherwiththepersistentdatainthe
systemthisimplementsasimplemodelofcomputationthatiseasytoprogramand
achievesahighlevelofreliability,withouthavingtobeconcernedwithpersistence,
consistencyandstabilityofvirtualmemory.
Eachprocesshasitsownaddressspace.Addressspacesarea(notnecessarily
contiguous)collectionofpages.Thepagescanbesharedbetweendifferentaddress
spaces.Therearenorestrictionsonwheresharedpagescanbemapped.Thisrules
outstoringabsolutepointersinsharedpages.
Processesarescheduledbythekernel.Everyprocesshasafixedupperlimitof
CPUtimeitmayuse.ThereisnoguaranteethattheallottedCPUtimewillbe
assignedinasinglecontiguousunit,becausetheschedulermayswitchtoanother
process,toachieveacceptableinteractivebehaviourortoexecuteaprocesswitha
higherpriority.Theinternalprocessstructureofthekernelisnotspecifiedbecause
itisinvisibletotheuser.Thelow-leveldevicedriversandthecheckpointingfacility
aretypicallytheonlykernelservicesthatmayneedtheirownprocesses.
Likemanymicrokernelsithasthetendencytohavemanyprocesses,withthe
vastmajoritybeinginactive.InthedescriptionoftheUNIXemulation[30](which
usesseveralprocessesperUNIXprocess)thedevelopersstate:
“ReactionstotheKeyNIXdesignfromUNIXdevelopersrangefrom
shockedtoappalledattheprofligateuseofprocesses.”
Overallthememoryandprocessmanagementimplementationisfairlyelegant
(ignoringthepropertiesthatcomefromtheout-of-processmodel),providingavery
abstract,processor-independentinterfacetothehardware.Thekernelhasbeen
portedtoseveralprocessorarchitecturesotherthantheIBMSystem/370(including
theMotorola68000).Thekernelinterfaceishardtoimplementefficientlyonmany
.howeverarchitectures,processorTheusualaccountingproblemswithout-of-processsystemsapply.Theuserofa
service(throughanRPC)isnotdirectlycharged,aviolationofthedesignaims.

64Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

MechanismProtection3.2.3ProtectioninKeyKOSisbasedexclusivelyoncapabilities.Acapability(inKeyKOS
calledkeyforbrevity)mustbepresentedexplicitlytoaccessaserviceorobject.A
capabilityisbothnecessaryandsufficienttogainaccess.TheKeyKOSkernelonly
supportssixfundamentalobjecttypes.Allofthemarerelatedtoprotection:
devices:Hardware-dependentpartsofadevicedriverwhichcoordinatethetrans-
lationfrommessagestohardwareregistermanipulationsareincludedinthe
kernel.Adevicedriverismainlyimplementedasuser-levelcodeunlessthe
high.unacceptablybecomespenaltyperformancepages:ThesimplestobjectinKeyKOSisapage.Apagereactstoreadandwrite
messages.Theloadandstoreoperationsperformedbytheprocessorare
equivalenttoreadandwritemessagestotherespectivepageasdefinedby
theaddressspace.Ifapagetobeaccessedisnotinmainmemorywhena
messageissent,thenitisbroughtintomemorybeforesendingthemessage.
Eachpageisidentifiedbyapagekeyandhasapersistentlocationondisk
.locationhomeitscallednodes:KeyKOSstorescapabilitiessegregatedfromnormaldata,inaspecialvari-
antofapagecallednode.Thispreventsforgingofcapabilities.Anodemay
holdafixedimplementation-specificnumberofcapabilities(inallimplement-
ationsavailableithas16slots).Anodekeyisrequiredtogainaccesstothe
capabilitiesinanodeortostoreacapabilityinanode.
segments:Asegmentisacollectionofpagesorothersegments.Segmentsare
sparseandmaydefineanon-contiguousareainmemory.Anaddressspaceis
definedbyasinglesegment,whichisimplementedasatreeofnodes,with
pagesastheleavesofthetree.
meters:TheholderofameterkeyisentitledtotheamountofCPUtimerecorded
inthemetercorrespondingtothecapability.Newmeterscanbecreated,
butonlyasasubmeterofanothermeter.Thiscorrespondstoahierarchical
allocationofCPUtime,whichislessrestrictivethanhierarchicalscheduling.
domains:Adomaindescribestheenvironmentofaprocess.Itconsistsof16gen-
eralkeyslots,anumberofspecial-purposekeyslotsandallthenon-privileged
stateofthehardware(suchastheregisterset).Thedomainisdeemedtohold
thekeywhenaslotisloadedwithacapability.Themostimportantspecial
slotsforadomainarereservedforasegmentwhichdefinestheaddressspace
andforameterkeywhichprovidesexecutiontime.
Creatinganewcapabilityisaprivilegedoperationandreservedtothekernel.
Thekernelensuresthatcapabilitieshaveauniqueidentifier.Theuniqueidentifier
mustbegeneratedexplicitly(e.g.withacounterstoredinvirtualmemory)since

OSeyKK3.2

65

thevirtualmemoryaddressofanobjectisnotunique.Therighttocopyacapability
andpassittoathirdpartyisavailabletoeveryone.
Revokingcapabilitiesisaproblem,astheowneroftheobjecthasnocontrol
overcapabilitydistributionoruseofthesegment.Thereisnogeneralsolutionin
KeyKOS,butinthecaseofacapabilitytoaprocessitispossibletoavoidthedrastic
measureofdeletingtheprocess.Severalsuchcapabilitiestoasingleprocesscanbe
definedanddistinguishedlater.Individualprocesscapabilitiesmaybeinvalidated,
revokingaccessofacertainsetofclients.
Theuniform,strongprotectionsystemisasuitablebasisfortheintendeduse
inasystemwithmutuallysuspicioususers.Ontheotherhand,itisimpossibleto
preventcapabilitiesfrombeingpassedontootherusers,unlessthereareabsolutely
noshared,writableobjects.Thisisnotpossibleinmostapplicationscenarios,
thereforeinformationleakscannotbecompletelyprevented.Userscancollaborate
togainmoreaccessthanthesecuritypolicyallows,iftheapplicationrefrainsfrom
.layersecurityanotherimplementingKeyKOSincludesanexceptionmechanism,whichrelaysexceptionmessagesto
anassociateddomain,calledthekeeper.Thereisaseparatekeeperperdomain,
segmentandmeter.Segmentkeepersareinvokedifaprotectionviolationoccurs.
Meterkeepersareinvokedwhentheassociatedmeterrunsout.
Domainkeepersareactivatediftheprocessthatexecuteswithinthedomain
causesaninterrupt(systemcall,arithmeticerrororinvalidoperations).Theyplay
animportantroleinemulatinganoperatingsystem.

Communication3.2.4Amessageconsistsofaparameterword,astringofupto4096bytesandfour
capabilities.Onlycapabilitiesheldbythesendermaybeincludedinthemessage.
KeyKOSsupportsonlylocalmessageexchange.Remotemessageexchangecanbe
implementedasauser-levelservicewithproxyprocesses.
Thestandardmessagesendmechanismiscall,whichgeneratesaresumecapab-
ilityanddispatchesthemessagetotherecipient(includingtheresumecapability).
Thesenderissuspendedandrefusesmessagesuntilitreceivesamessagesentwith
theresumecapability.Avariantofthecallmechanismistheforkmechanism,which
doesnotgeneratearesumecapabilityanddoesnotwaitforareply.
Messagesarenotbufferedbythekernel.Iftherecipientisnotreadytoreceive
amessageimmediately,thenthesenderofthemessageissuspendeduntilthe
receiverisready.Bufferingcanbeimplementedthroughaproxyprocess.
ThissynchronousRPCmechanismcanbedescribedinthein-processmodelwith
asubroutinecall,sincethereisonlyasingleprocessabstraction.Asaconsequence
ofthemessage-basedmodel,theaccountingworksperobjectandnotperuser.
Thecapability-basedRPCmechanismavoidsmanyauthorisationproblems.The
callermustprovideacapability,whichisdefinedtobesufficientproofofauthorisa-
tion.Ifthisisnotenoughforaspecial-purposeservicethenfurtheraccesschecks

66Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

canbeimplementedintheserver.Revisingtheaccessrulesrequireseitherdistrib-
utingnewcapabilitiesorchangingtheservercode.
Synchronisationbetweenprocessesisonlypossiblethroughcalloperations(or
busywaiting).Synchronouscoroutinescanbeimplementedthrough“creativeuse
ofcalloperations”[30].InKeyKOSsynchronisationcodeconsistsmainlyofpro-
grammingtrickswhichrelyonside-effectsofmessagefunctions,whichmakesit
hardtounderstandandverify.Sometimesadditionalprocessesaretheeasiestsolu-
tiontoimplementaparticularsynchronisationprotocol.
Implementingstandardsynchronisationprotocols(e.g.countersemaphores)is
complicatedanderror-prone.Thisisnotacceptableforasystemthatdefinessecure
sharingofdataasoneofitsfeatures.

SummaryandDiscussionCritical3.2.5KaneyKOS,OSiswhileaverystillearlyprovidingattemptaatversatile,integratingflexibleeffectivebaseforaprotectionvarietyofintoOSthedesigns.kernelofIt
isoneofthefewcommerciallysuccessfulcapability-basedoperatingsystems.
KeyKOStriedtoreducekernelfunctionalitytoaminimum,withoutsacrificing
securityordeclaringminimalsizetobeadogma.Themostimportantproperties
ofKeyKOSaffectingitsusabilityandsecurityare:
a)makeLow-levelituser-leveldevicecodedriverswitharefullyonlyselected,privilegedcode.minimalItwouldprivileges.bemoresecureto
b)Thecheckpointinglogicinthekernelstopsapplicationexecutionatregular
intervalstowritealldirtypagestothedisc,causinglongdelays.
c)Noefficientsynchronisationmechanismsforsharedmemorysegments(files).
d)Rentinepresentationpersistentofanddatamainstructuresmemorythat,toareincreaseaccessedbyefficiencythe.kernelThecanbeauthoritativediffer-
dataisalwaysstoredinpersistentmemory.
e)theProcessinformationschedulingthecanschedulerbebasessupplementeditsbydecisionsuser-levelon.codethatmanipulates
f)Operatingsystememulationswithfullbinarycompatibilityarepossible.
g)UserOut-of-processauthenticationandimplementationaccountingcausingarethemajorusualproblems.processnumberexplosion.
h)ilityStrongdistribution.protectionsystemConfinementbasedisonhardtocapabilities,achieve.butlittlecontrolovercapab-
usefulTheKeyKfunctionsOSkernelrequiredisbysmallapplications.enoughtobeTheonlyunderstandable,majordeficiencyyetisprovidtheeslackmanyof
theefficientprocesssynchronisationmanagement,mechanisms.maintainingfullThiscouldcompatibilitybewithcorrectedexistingwitharedesignapplications.of

MONADS3.3

MONADS3.3

67

Theniquesprojectforthebeganindevelopment1976ofwiththecomplexobjectivesoftwareofsystemsinvestigating[130,131],methodsagainstandtech-the
softwarebackgroundindustryofagrowing[198,226].awarenessTheoftermthesoftwaredifficultiescrisisthenbeingdescribedtheexperiencedunexpected,inthe
difficultiesexperiencedwithdevelopingusablelargesoftwaresystems.
Itsystem,wasbecausedecideditthatwasthefirstconsideredstageaofgoodthecaseprojectstudyshouldofabetocomplexdevelopsystemanandoperatinglater
researchwouldneedagoodOSasabasisforfurtherinvestigations.
ThefollowingdescriptionfocusesontheMONADS-PCsystem,thenewestwork-
ingdesignversion.arealsoAfewincluded.planned,Laterbut,moreunimplementedradicaldesignspartsofsuchofasthetheMONADSMONADS-MMsystem
massivememorysupercomputer[241]neverreachedtheprototypestage.

3.3.1AimsoftheMONADSProject
Theprimaryaimwastoinvestigatetheimpactoftheinformation-hidingprin-
ilitycipleof[215,216,information-hiding217]onthetolargedevelopmentsoftwareoflargesystemswassoftwarenotsystems.universallyTheaccepted.applicab-
(cf.[187,MONADS34]),isnotbuttheitfirsttakesOSthetobeadditionalconstructedstepoffromencouraginginformation-hidingapplicationstomodulesbe
decomposedintoinformation-hidingmodules.Infact,OSandapplicationmodules
followThetheMONADSsameOSstructuringwasdesignedconventions,tosupportwithnostrongfreestandingprotection,databasedonsegments.theright
tothecallpermittedaninterfacecallroutinedestinations.ofaAllmodule.communicationTheprocessisperformedenvironmentthroughdeterminesshared
Themodules.modulesThisarerequireskeptinappropriatevirtualsupportmemory,forwithsynchronisingappropriateconcurrentaddressingaccesses.environ-
mentseparationtopreventaccessesthatviolatetheinformation-hidingprinciple.
tionThreeofkeyactivity,structuringmodulesareconceptstheonlyweresoftwareidentified.buildingbProcesseslockareandthetheonlybasisforabstrac-pro-
tectionintroduced[230],byandconventionalpersistentfilevirtualsystemsmemoryanddatabaseeliminatesthemanagementarbitrarysystems.complexity

Structure3.3.2Asmentionedabove,thewholesystemisdecomposedintoinformation-hiding
ismodules.similartoAllmodulesobject-orientedprovideaprogrammingcertain[49],well-definedbutOOPinterfaceremainedtotheirrelativelyclients.Thisun-
wareknownunitsuntilthanthe1980s.programming-languageModulesinMONADSobjects.[140]Theyarearetypicallypassiveandmuchcanlargerbecalledsoft-
inthecontextofanyprocess,assumingthecallerhasappropriatepermission.

68Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Morespecifically,inthecontextoftheMONADSproject,amoduleisacombina-
tionofcodeand(fullyencapsulated)data.Thecallableinterfaceroutinescomprise
theexportedinterfaceofthemodule.Internallytheremaybemanymoreroutines,
whichcanbeusedbothbytheexportedandinternalroutinesofthemodule.
Everysoftwareobject(regardlessifitisapartoftheOSoranapplication)in
theMONADSsystemisamodule.Programs(inwhichnopersistentdataisstored
beyondtheirexecutionandwhichhaveasingleentrypoint),librariesandconven-
tionalfilescanallbeeasilyrepresentedasmodules.
TheMONADSOSisbuiltasaflexiblesetofmodules[284]aboveakernelthat
implementspersistentvirtualmemory,processes,theprotectionsystemanddevice
drivers.ThisHardwareKernel[236,237]simulatestheidealhardwarefortheOS.
Thekernelispartlyimplementedasmicrocodeandpartlyasaspecial,privileged
modulewhichprovidestheremainingfunctionalitywhichwouldbetoocomplic-
atedformicrocode(suchastheCPUschedulerandvirtualmemory).Theimple-
mentationtreatsthekernelaspartofthepersistentmemoryandthusitsstateis
generallypersistent.Onshutdownsomekernelstatethatrelatestonon-persistent
partsofthesystemisintentionallydestroyed,suchasdevicedrivers.
Alargepartofthekernel(especiallythescheduler,thedistributedpersistent
virtualmemorymanagementandalldevicedrivers)isimplementedinassembly
codelanguage,discourageswhichmakesmodifications.ithardtoThisisaunderstandregressionanddebug.againstTheearliercomplexityversionsofofthethe
MONADSsystem,whichhadsimplerkernelsanddelegatedmorefunctionalityto
OSmodules,whichcouldbeimplementedinahigh-levellanguage.

ManagementMemory3.3.3firstThebasisdesignoffortheawholemodifieddesignisHewlett-Palargeackardpersistent2100A[293]virtualincludedmemorya(althoughseparatethefile
systemmentation[96]).andThepaging[134],MONADS-PCwhichcomputermadeitandpossibleOStohaveimplementedbothefficientorthogonalprotec-seg-
tionofvariable-sizedatastructuresandefficientvirtualmemorymanagementwith
fixed-sizepages.ComparedwithUNIX,itreplacedthephilosophyof“everythingis
afile”Thewithemphasis“everythingisthatisathereismoduleainuniformvirtualpersistentmemory”.virtualmemory.Thereare
subtledifferencestoorthogonalpersistence,thebuzzwordofthepersistentpro-
sistencegrammingisthatthecommunityatprogrammerthesamehastime.absolutelyPartofnothecontroldefinitionovertheofpersistenceorthogonal(i.e.per-
itisfullyautomatic).Withuniformpersistenceitiscontrollablewhenandhowa
casecertainthemoduleprogrammerismadedecidedpersistent.nottoTherecontrolaresuitablepersistence.defaultpoliciesthatapplyin
Segmentsareusedtorepresentlogicalunits[240]withinamoduleorprocess,
thatsuchasholdthesubroutines,descriptorsarraysforaandcurrentlyotherdataactivestructures.segmenttoTheremakeareaddresssegmenttranslationregisters

MONADS3.3

69

veryefficient.TheCPUimplementsboundschecking,whichdetectsmanyerrors
duetoincorrectmemoryaccesses.Thereissupportforrefiningsegments,giving
accesstoonlyawindowwithinthesegment.
Alldatacanbeclassifiedintofourdifferentkinds,withvaryinglifetime(although
persistent):arethemofalla)Type-relateddataisassociatedwiththecodepartofamodule.Allinstances
ofamodulesharethetype-relateddata.
b)Instancedataisassociatedwithaparticularinstanceofamodule,represent-
data.encapsulateditsingc)Retaineddataisassociatedwithaparticularclientprocessusingaparticular
module.Itcanrepresentstateinformationnecessaryacrossindividualcalls.
d)Localdataisassociatedwithaparticularcalltoaroutine.Itrepresentsin-
formationthatisonlyrequiredduringanindividualcall.
TheMONADS-PC[239]withits60bitswidevirtualaddressesimplementsdis-
tributedsharedmemory[106,107].Itsupportsuptofournodesinalocalarea
network.DSMsupportintroducesmanyfeaturestoimprovethefault-tolerance
(e.g.handlingdisccrashes).Thereissupportformigratingamodulewithouthav-
ingtochangeitsidentifier,e.g.totransparentlytransferamoduletothenode
whereitisaccessedmostfrequently.TheDSMimplementationisincludedinthe
kernel,withafewancillarymodulestomanagemigration.Thecompletein-kernel
DSMimplementationincreasedthecomplexityofthekernelsubstantially.
Itisenvisagedtoencrypt[94]thecontentofthepersistentstoragemediaand
thenetworkcommunication,topreventtheftormodificationofdata.Thisprotects
thesystemagainstattacksfromoutside,bymakingthedataaccessibleonlytothe
MONADSOS.Apublickeyinfrastructureisrequiredtohandlethekeydistribution
inadistributedMONADSsystem.Everynodemay(andshould)useadifferentset
ofencryptionkeysforitsowndataandtoexchangepageswithothernodes.
Thedesignallowsforahybridpublic-keyandsymmetricencryptionscheme,to
maximisesecurityandefficiency.Withpublickeyencryption,theciphertextmay
becomelongerthantheplaintext.Thisdoesnothappenwithsymmetricencryption
algorithms3,atleastnotforthepagesizedblocksusedinvirtualmemorymanage-
ment.Itismuchsimpleriftheblocksondischavethesamesizeasinmemory.
Modulesgenerallyconsistofcodeanddata.Eachofthepartsisstoredinits
ownaddressspace,afixed-sizepart4ofthevirtualmemory.Sincethisdefinitionof
anaddressspaceisdifferentfromthegenerallyacceptednotion,itwillbecalled
container,thenameusedbyafewotheroperatingsystems.
3withDESlongerwaskeysuggestlengtedhatwouldthetimebeRC5theorsecureAES.pagingschemewasdesigned.Todaygoodcandidates
4IntheMONADS-PCanaddressspacehasacapacityof256Mbytes,i.e.theoffsetwithinan
addressspaceis28bitslong.

70Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Thevirtualmemoryconsumptionofusersandmodulescanbecontrolled.Limits
canbesetforthenumberofpagesthatcanbeallocatedinacontainerandthetotal
numberimplementedofcontainersmainlyinausermicrocodecancreate.andaccountingAllocationofthereforepageshaswithinalimitations.containerTheis
containeraccountingisimplementedaspartoftheOSmodulesandcanbere-
notplacedsubjectbytomodulesresourceimplementingmanagement,otherbutispoliciesassignedifnecessarypurely.onPhysicaldemand.memoryis

ManagementProcess3.3.4Theimplementationfollowsstrictlythein-processmodel.Allmodulesandpro-
cessesarestoredinasingleaddressspace.Processesarestoredinvirtualmemory,
eachprocessinitsowncontainer.Thereforeprocessesarepersistent,asthetable
ofcurrentlyactiveprocessesinthekernelispersistent.
Thestackrepresentingthecallnesting(bothinter-moduleandinternalcalls)
isstoredinacontainer.Everyusercanhaveoneormoreprocesses,whichall
areassociatedwiththatuserthroughauniqueidentifierthatisassignedtoevery
user.LikemostMONADSoperations,creatinganewprocessisanoperationthat
requirespermission,allowingsystemstobeconfiguredtotreatthisasaprivileged
operation.Theoperationcane.g.bedelegatedtoaprocessmanagementmodule,
whichcanbetheonlymodulewiththerequiredpermission.
ThehardwareprocessesimplementedbytheHardwareKernelfollowdifferent
rules(out-of-process,processesarenotassociatedwithusers).Conceptuallythey
arenotpartoftheMONADSenvironment.
Thescheduler(whichcontrolsexecutionofbothhardwareanduserprocesses)
implementsseveralpolicies.Generallyallhardwareprocessesarescheduledwitha
fixedprioritypolicyanduserprocessesarescheduledround-robin.Thescheduling
policyispartofthekernelandcannoteasilybereplaced.

MechanismsProtection3.3.5IntheMONADSsystem,segmentsandmodulesareprotectedbytwokindsofcap-
abilities(sometimescalledtwo-levelcapabilityarchitecture).Thisensuresthatan
Theappropriateuniqueidentifiersprotectioninthemechanismcapabilitiesforthearebasedrespectiveonthesoftwarecontainerunitcannumberbe,applied.which
isneverreused.Thepossessionofacapabilityissufficienttogainaccess.
moduleSegmentscapabilitiesaretypedorafew(containingothernormkindsalofdata,data).segmentThemicrocodecapabilities,checkssemaphores,whether
thetypeoftheaccessedsegmentiscompatiblewiththeintendedoperation.There
iscannobeoperationreducedtothatread-onlycreates,tocapabilitiespreventwithaccidentalarbitraryormaliciouscontent.Accessmodificationtoofsegmentsdata
a(e.g.segmentconstantscapabilityorcode).forAit.Asegmentsegmentcanonlycapabilitybeaccessedmayifonlythebeprocessstoredcaninanotherprovide

MONADS3.3

71

segmentifthiswouldnotviolatetheinformation-hidingprinciple,generallyonly
in(whichsegmentsmaintainwithintheinformationsamehidingcontainerif.usedThereresponsibly),aresomee.g.toexceptionsimplementtothiscall-by-rule
referenceparametersortheretainedstorage.
Modulesarealsoprotectedbycapabilities,howeverofadifferentkind.The
identifierforamoduleistheinstancecontainer(ifthereisnoinstancecontainer
thentheidentifierofthetype-relatedcontainerisused,e.g.forprograms).Ac-
cesstoindividualinterfaceroutinescanbegranted,implementingsemanticaccess
facerights.routinesThishascansecuritycontroltheadvantages,accesstoasinformationfine-grainedmuchaccessbetterrightsthanbasedbasiconaccessinter-
rightsforfreestandingdatasegments.Howeverrevocationisasevereproblem,
andthorisedtheonlyusergainssolutioninaccesstoMONADSaiscapabilitytocopyforit.andThethennewdeleteacapabilitymodulethenifanneedsunau-to
bedistributedtothelegitimateuserstogivethemaccesstothemodule.
atedModulecapabilities),capabilitiesbutcantheyonlyarebecompletelystoredinunderspeciallyusertypedcontrol.segmentsUsers(i.e.arefreesegreg-to
storeisationiscapabilitiesthatcapabiinanylitiesarecontainerstoredtoinwhichdirectoriestheyhave(modulesaccess.Athatcommonmanageaorgan-list
ofusercapabilitiesmodules,withgivingassociatedmaximumfreedomhuman-readabletoorganisenames).theinformation.DirectoriesFareorcertainnormal
ory(wheresecurity-sensitiveitcouldmodulepotentiallycapabilitiesberetrieveditcanbybesomeusefulothernottouser),storebutthemdirectlyinaindirect-the
modulethatneedsaccess,withnomeanstoretrieveitagain.
Thekernelmodulethatcontrolstheschedulerrequiresaspecialprocesscapabil-
ity(avariantofamodulecapabilitythatreferstoaprocesscontainer)ifaprocess
otherthanthecurrentprocessshouldbecontrolled.Thisensuresthatonlyusers
withappropriateprivilegescansuspendoractivateprocesses.
generallyConfiningpossible.theflowOnlyofveryinformationsimplebetweenconfinementmodulesproblemsandcanbebetweenadequatelyusersisim-not
ingplementedthemfrombysettingbeingupcopiedthe(whichrequiredismodulepossiblebycapabilitiesunsettingthecarefullycopyandbymetaright).prevent-

SynchronisationandCommunication3.3.6CommunicationinMONADSisonlypossiblethroughsharingmodules,resultingin
acommunicationstructurethatisultimatelybasedonsharingsegmentsinvirtual
memory.Thiscommunicationmodelissimpletounderstand,andprogrammersare
usedtoitasitisthenormwithinaprogram.Howeveraccesstosharedmemory
requiressynchronisation,orinconsistenciescouldbecreatedbyconcurrentlyex-
ecutingprocessesthataccessandmodifycommonsegments.
Implementingsynchronisationbasedonmonitorswasrejectedbecauseitcreates
structuralproblems[129,224]andpotentiallymoremutualexclusionthanstrictly
necessarytokeeptheimplementationunderstandable.Instead,theresponsibility

72Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

foradvancedsynchronisationsynchronisationwasdelegatedprimitivestothe[133,individual135],basedmodules.onItDijkstra’swasgeneralenvisagedsema-that
ofphore,implementingwouldbepopularimplementedinsynchronisationmicrocode.Theprotocols.aimwasThetoentryreduceandtheexitcodecomplexityfor
criticalregionsshouldbeeasytoprogramandverify.
theyTheuseanhardwareout-ofprocesses-processwithincommunicationthekernelmodel.areThistreatedmodelspeciallyis,usedande.g.forgenerallythe
thedeviceoveralldrivers.OSorHoweverapplicationthisisstructure.invisibleoutsidetheOSkernelanddoesnotaffect

AccountingandAuthentication3.3.7TheCPUprovidesasetofinstructionsthatquerythecurrentexecutionenviron-
ment.retrieved,Theandidentifiersalsotheofcodetheandcurrentlyinstanceactiveofuserthe,callingstack,codemodule.andThisinstanceallowscanforbe
flexibleper-useraccounting.Additionallyonecancheckforunauthorisedaccesses
oridentifiersimplementitreturns.accessNoteauditing.thatThethekernelidentifieritselfguaranteescannotthebeusedtrustworthinesstocallaofallmodule,the
sincethereisnowaytoforgecapabilities.
Thethenticationsupportforschemepersistent[141].Themodulessystem-definedandprocessesloginalsoserviceenablesonlyaasksveryforthesecurenameau-
ofability),thebutprocessdoestobenotaskactivatedfora(auserpassworddirectorylikemanyprovidesothertheoperatingnecessarysystemsprocesswouldcap-
do.Insteaditdirectlyactivatestheprocess.Asprocessesarepersistent,theycon-
thattinueherightonlyaftercallsthethelogoutlogoutoperationoperationifintheyaaremodulereactivated.thatverifiesThetheuserusercanidentityarrange
Ifafteritisthenot,processthentheisprocessreactivated.isTheimmediatelymoduleloggedonlyoutreturnsagain,iftheformingcheckaisloop.successful.
Thiswaytheuserisfreetoimplementanyauthenticationmechanism,including
challenge-responseauthentication.Thereisnocentraltableofpasswords(which
isfrequentlythefirsttargetthatisattacked)orauthenticationmechanisms.An
attackercannotguesswhatinputisexpectedforthechecktobepassed.Themore
diversetheauthenticationimplementationsare,themoresecureisthesystem.
Thecustomoutputbytheauthenticationitselfcanbesetupsothatitcannotbe
beenforged,installedtrickingbyaanuserattackerintotoenteringharvesthisthecredentialsrequiredatafakeauthenticationauthenticatorinput.thathas
Aside-effectofthisdecentraliseddesignisthatitisimpossiblewithoutfurther
modulemeasuresthattoforciblyimplementslogtheoutauser.authentication.TheOSFhasorciblynomeansloggingofoutalocatingprocessthecanrequiredonly
suspendtheprocess,butthennoauthenticationwouldberequiredtoreactivate
thesolvedprocessbyandtreatinggainforciblyaccesstologgedtheoutcurrentlyprocessesrunningspecially,program.e.g.byThisrequiringproblemcanpersonalbe
person.trustedathroughauthentication

3.3MONADS

73

Anotherkindofauthenticationproblemistoensurethatthesystemitselfhas
thecorrectfunctionalityanddoesnotcontainsecurityflaws[94].Ingeneral,users
arepracticallyunabletocheckintegrityandtheOSproducercannottakeanyre-
sponsibility,asthesystemcouldhavebeenmodified.Ultimately,theintegrityof
theprocessoralsoneedstobeverified.Butthemanufactureroftheprocessoris
notinapositiontocertifythecompletesecuritykernelintegrity,butcanonlytake
theresponsibilityforhispartofthesystem.
Thereforethetaskmustbesplitbetweentheinvolvedparties.Thisispossible
byusingencryptiontechniques,especiallypublic-keycryptography[249].Every
security-criticalcomponentofthewholesystem(i.e.theCPU,thebootstraploader
andthesecuritykernel)needstobecryptographicallysigned,withthesecretkey
oftherespectivemanufacturer.Thisensuresthatonlythemanufacturercanbethe
signature.theofissuerThesignatures(whichmustbecheckedateverybootstrap)certifythatthepro-
cessorandOSrespectivelyarecorrectandhavenotbeenmodified.Thecertificates
mustbekeptinaprotectedstoragearea,e.g.memorythatcanbemadeinaccess-
iblebythekerneluntilthenexthardwarereset.
TheOSprovidesaservicetoquerytheCPUandbootcertificate,whicharesigned
bythesecretkeyoftheOSandprotectedagainstreplayattacks.Otherwisea
modifiedOScouldreturnapre-recordedanswer,pretendingtobethegenuineOS.
Encryptionisusedtoimprovesecurityandtrustworthiness.

InterfaceUser3.3.8TheOSprovidesaninnovativecommand-lineinterpreter[109,110,76],whichal-
lowsanyinterfaceofanymoduletobecalled(subjecttotheusualcapability-based
accesschecks).Theresultingcommandlanguageinterpreterismuchmoreflexible
andversatilethane.g.aUNIXshell,whichisrestrictedtoprogramswithasingle
entrypoint.Debuggingofnewmoduleimplementationsandcertainmaintenance
workcanbeperformedwithoutwritingcustomprograms.
Agraphicaluserinterfaceisalsoenvisaged[29],butwasneverincludedinthe
standardOS,becausetheMONADS-PCcomputerhasonlyarestrictedsetofperi-
pheralsforcommunication.InthecitedprojectthedisplayhardwareofanApple
Macintoshcomputerwasused,andcommunicationwiththeMONADS-PCworked
overaRS-232serialline.Theresearchinthisareaonlyscratchedthesurface.
BoththetextualandgraphicalUIhadproblemswiththefactthattheMONADS-
PCimplementedapersistentsystem,whiletheoutsideworld(whatisdisplayedon
theterminal)lostitsstatemuchmorequickly.Whenauserloggedout,thedisplay
contentwasoverwrittenbythesystemloginprocedureandpossiblytheactionsof
otherusersthatusedtheterminalinthemeantime.Iftheoriginaluserloggedin
again,theapplicationwasstillinthestatewhereheleftit,butthedisplaydidnot
reverttoitspreviousstate.Thisofcoursecanbesolved,butinthecontextofthe
MONADSprojectitwasnotdeemedimportant.

74Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

SummaryandDiscussionCritical3.3.9TheMONADSprojectproducedaprototypethatsuccessfullyimplementedmostof
itsobjectives.Itcanbeusedasabasisforaverysecuresystem,butitalsohelped
weaknesses:severalidentifyinga)Capabilityrevocationisnotsolvedadequately.Itwouldbedesirabletospecify
furtherconditionsthatmustbefulfilledbeforeanaccessispermitted.
b)Itwouldbeusefulifdynamicaccesschecksandaccessauditingcouldbe
implementedasseparatemodules,tobedynamicallyboundtoanymodule.
c)Implementingconfinementisonlypossibleforsimplecases.
d)ManyOSfunctionscouldbedelegatedtomodulesiftherewasasecuremech-
anismforintegratinge.g.pagefaulthandlinginthemodulewithouthaving
toreimplementthisforeverymoduletype.
e)Toomuchoftheimplementationisinassemblylanguage.Thekernelistoo
bigtobeeasilyverifiable,asitincludesalldevicedriversandthecomplete
implementation.memoryshareddistributedf)DSMimplementationneedstobeenhancedtobeusableforcommunication
linkswithlargerlatency,e.g.byreplicatingcontainers.
g)Resourcemanagementonlyappliestocertainresources,andisgenerallynot
design.systemtheintowell-integratedh)Persistentuserinterfacesneedmoreresearch,asthepropertiesoftheaffected
peripheralsisunlikelytobechanged.
i)Customprocessorarchitectureprovedtobeamajorproblem,becauseitmade
itdifficultforotherresearcherstoadoptthesystem.
Thesystemprovedtheapplicabilityofinformationhidingtolargesoftwaresys-
tems,especiallyoperatingsystems.Italsoprovedthatanin-processimplementa-
tionwithpowerfulmoduleprotectionthroughcapabilitiesisaviable,securealtern-
ativetothetraditionalOSdesigns,withoutmakingsharingaproblem.Theoverall
efficiencyandflexibilityofthesystemcomparesfavourablywithmanywell-known
systems,andmuchhighersecuritycanbeachieved,e.g.withthedecentralised
authenticationmethod.Encryptionisusedonlyagainstexternalattacks.
Manyofthefeaturescantoday(withthewideavailabilityof64bitprocessor
architectures)beimplementedoncommerciallyavailablesystems.Howeverthis
requiresscrappingalargenumberofnice-to-havefeatures,suchaspropersegment-
ation.Thismainlyleadstoareductioninresilience,butdoesnotaffectsecurity.
ApplyingmicrokernelandRISCprinciplestothedesigncanreducethecomplexity
ofthekernelwithoutsacrificingsecurityorefficiency.

Amoeba3.4

Amoeba3.4

75

OneofthefirstradicalattemptstomoveawayfromlargemonolithicOSkernelsis
TtheanenbaumAmoebaetal.microkernelin1981based[274,278,distributed279].ItsoperatingmainaimsystemwastodesignedsupportbyAndrewdistributedS.
systems(includingsupercomputerswithhundredsoflooselycouplednodes).
areaTofogetherbothwithmicrokernelsMach(seeandsectiondistributed3.6)itwasoperatingthesystems.foundationofUnlikeresearchMachitinwasthe
nottemsadoptedcloselyasrelatedthetobasisforAmoebaarecommerciallyGlobe[270]availableandPoperatingarameciumsystems.[64].Othersys-

ManagementMemory3.4.1Eachprocessdefinesaseparateaddressspaceconsistingofanumberofactive
segments,whicharemappedinatarbitraryaddresseswithintheaddressspace.
Memoryismanagedbythememoryserver.Itissuescapabilitiesforsegments,
whichcanthenbeusedtoaccessthecontentsortopasstheaccessrightstoother
processes.Thememoryserverispartofthekernel,butlookslikeusercode.
theSegmentssegmentisarenoalwayslongerpresentmappedinintophysicalanyprocessmemory,untiladdressspaceexplicitly5.Theydeleted,areevenneverif
swappedorpagedtothevirtualmemorybackingstore,infactthereisnovirtual
memoryatall.ThissimplifiesthekernelandmakessurethatRPCoperationsnever
blockduetovirtualmemoryoperations.Thisisclaimedtoincreaseperformance
andtobeeconomicduetothedecreasingcostof6memory.Itisalsoarguedthat
supercomputerstendnottosupportvirtualmemory.
nelTheleavesverylittlesimpleopportunitymemoryformanagementuser-leveleschemenhancements.implementedAllactiveinthesegmentsAmoebausedker-
iswithintightallthenacurrentlyprocessactivewhichprocesseswantstoareallocatepermanentlyasegmentpresentinexceedingmemorythe.Ifsizeofmemorythe
availablephysicalmemoryhastowaituntilenoughspaceisavailable.
haviourSuchacouldsimplisticbepredicted,resourcewhichmanagementisnotevenwouldbeattemptedacceptableinmostifallapplicationgeneral-purposebe-
operatingsystems.TheresourcemanagementfacilitiesinAmoebaareinferiorto
fullythose.AinsingleUNIX.Amoebamisbehavingisunableapplicationtohandlewhichonlytemporaryallocatesresourcememoryshortagesandgrace-never
releasesitthreatenstheavailabilityofthewholesystem.
isThetrueimplementedcauseinofthethekernel,simplisticasthemanagementimplementationseemstoofbeathatusablethevirtualmemorymemoryserver
systemiscertainlybeyondthescopeofamicrokernel.
65ThisGarbageargumentcollectionhascannobecomethelpobsoletemuch,overasthetherelastmightyears,stillbebecausecapabilinowtiesevenforthesupercomputerssegment.have
beenthosesystemsenhancedaretoundmakeerbetterpressureusetoofmakethegoodavailableuseoftheresourcesavailablandeimplementresources.virtualmemory.Even

76Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

The“memorywholeischeap”issueofassumptionresourceisallocationconsidereddeadlocksanisoversimplification.effectivelyunansweredifthe

ManagementProcess3.4.2threadProcessesofinexecution,AmoebaanareaddresssimilartospaceUNIXandsomeprocesses,asresources.theyinitiallyAmoebaisincludebasedaonsinglethe
message-passingparadigmandimplementstheout-of-processmodel.
addressLaterthespace.initialAllthreadsthreadcanwithincreateoneprocessfurthersharethreads,asinglewhichprocessorexecute,inwhichthemeanssame
thattheyexecuteinaquasi-parallelwayonly.Thebehaviourisasifthreadswere
bytheimplementedkernel,asinatheuser-levelsensethatconceptanotherwithoutthreadiskernelactivatedsupport.whenThreadsaarecurrentlyscheduledactive
threadblocksduetoanI/Ooperation.Thelimitationsoftheschedulerarean
integralThepartAmoebaofthekernelkernelitselfandconsistscannotofbeseveralenhancedthreadsbythatuser-leveloffercode.servicestouser
processes.Oneexamplewasmentionedintheprevioussection,thememoryserver.
theProcessnewlycreatedcreationisprocessalsoshouldmanagedhavebytheaccessmemoryarepassedserver.toAllthecreatesegmentstoprocesswhichop-
erationofthememoryserver,whichsetsuptheprocessdescriptor.Theoperation
returnsprocessaortoprocessgetaccesscapabilitytoits,datawhich(e.g.cantobedebugusedit).tocontroltheschedulingofthe
Aprocessiscreatedonthenode7onwhichallthesegmentsitconsistsofare
stored.Thismakesitpossibletocreateaprocessimmediatelyonanothernode,
theandnodeavoidtheymigratingshouldallexecutenewlyon.createdItisprocenotssespossiblefromtothehavenodesomeoftheirsegmentscreatoroftoa
processononenodeandsomeonanother.
UNIXsignals,Synchronisationexceptthatbetweentheythreadscanbecansentbebetweenperformedthreads),usingsignalsmutexes(whichandarecountinglike
tousesemaphoresto.achieveTheseaarehighlevelefficientoflow-levelparallelismwithsynchronisationminimalexclusion.operations,butarehard

Structure3.4.3Thesystemisstructuredintoservices,eachwithanassociatedserverprocess,
whichprovideanabstractinterfacetousers(e.g.filestorageservices,memory
server).ThisstructuringmechanismcanbeusedtodecomposetheOScodeinto
servicesthateachprovideonlyasingleabstraction.Amoebaavoidsthelarge
amorphousmassesofcodetypicalformonolithickernels.
Aservicecancontainseveralobjects(identifiableusingcapabilities).Invocation
ofobjectsispossibleonlythrougharemoteprocedurecall,whichtransfersexecu-
7Allprocessorstogetherconstitutetheprocessorpool,someofwhichmayprovidespecialservices.
Acompletecomputersystemiscallednode.

Amoeba3.4

77

tiontotheprocessoftheservice.Thethreadwhichcalledtheserviceissuspended
untiltheresponseissentbackbytheinvokedservicethread.
Thisfairlycomplex,non-orthogonalserviceorganisationintoobjectsandthreads
limitstheOSflexibility.Remoteprocedurecallsalwaysswitchtoadifferent(heavy-
weight)process,buttheexecutionisdefinedtobesynchronous.Themultitudeof
processesandthreadsarethereforenotasuitablebasefortrueconcurrentactivity,
asmostservicesonlyoperateondemand.Thedemandislimitedbythenumberof
usersinthesystem.Thelargenumberofthreadswithinaserviceisnecessaryjust
toavoidbottlenecksduetoconcurrentuseractivitywithinaservice.
Devicedriversareimplementedasuser-levelservices.TheAmoebakernelde-
pendsonveryfewdevicedrivers,whichminimisestheassumptionsmadeabout
theinterfaceofdevicedrivers.Theinterfacetomostdevicedriverscanbefreely
designedtooptimallymatchtheremainingsystemdesign.
Filesystemsarealsopurelyuser-levelservices.Severalimplementationshave
beendeveloped,rangingfromverysimplefilesystemstofilesystemscapableof
simulatingfullUNIXsemantics.Theinterfaceisfullyuser-defined,asthekernel
itselfdoesnotneedtoaccessfiles.
Manypapersfocusonthebulletserver(e.g.[277]),whichisahigh-performance
filesystemoptimisedforcaching.Itonlysupportscreatingnewfiles(immediately
providingallthedata),readingfilesanddeletingfiles.Filesareidentifiedwith
RPCcapabilities,whicharereturnedbythecreateoperation.Everyfileisstored
inasinglecontiguousareaondisc.Thebulletserverreadsthecurrentlyaccessed
filescompletelyintomemory.Theassumptionisthatthefileserverhasenough
memorytofitallconcurrentlyaccessedfilesandanumberofthemostrecentlyand
frequentlyaccessedfilesentirelyintomainmemory.
Thisspecial-purpose(formostapplicationstotallyinadequate)filesystemhas
beencompared(see[229])withSun’snetworkfilesystemNFS.Thebulletserver
achievedmuchbetterperformancemeasurements(bothforlatencyandthrough-
put)thanNFS.Therelevanceofthisresultisquestionable,becauseitignoresthe
differentfunctionalityprovidedbythebulletserverandNFS.NFSalreadyprovides
modifiablefilesandahierarchicalnamesystem,whichisimplementedinAmoeba
withotherservicesnotincludedinthemeasurements.
OfcourseAmoebaalsoprovidesafilesystemwithmodifiablefiles,butthisworks
bycopyingthecontentthathasnotbeenmodified,causingmanymorewriteac-
cessesthanforusualfilesystemimplementations.Thesemanticsofimmutable
filesmatcheswrite-once,read-many(WORM)media,buttodaydirectlyoverwrit-
ablemediaarestillthenorm,providinghigherspeedandcapacity.
Includedinthehigher-levelfilesystems(andalsoinotherservicesnotdiscussed
here)isamechanismforchargingforfileoperationsorstorageconsumption.A
bankserverprovidesdifferent(convertibleornon-convertible)currenciesinthe
formofcapabilities.Thefilesystemserverchargescertainfees(upfront)perfile
operationorblockallocation.ThisisdifferentfromtheMonashPasswordCapab-
ilitySystem(seesection3.5)approachofchargingarentfortheallocatedspace,
whichprovideslivenessinformationforobjectsinthecontextofgarbagecollection.

78Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Communication3.4.4Amoebausesaclient-serverstyledistributedprocessingmodelimplementedwith
RemoteProcedureCalls(RPC)tocommunicatebetweenthreadsinthedistrib-
utedsystem.Sharedmemoryisexploitedtoimprovetheperformanceofmessage
passing,iftheprocessorarchitecturesupportsit.AmoebaRPCsupportsat-most-
oncesemantics,whichguaranteesthatanRPCisneverexecutedmorethanonce,
regardlessofpotentialservercrashesandrestarts.
TheRPCcommunicationschemeissupplementedbyareliabletotally-ordered
groupcommunicationmechanism,whichguaranteesdeliverytoallmembersof
thegroup,unlesstheuser-levelsequencerservicecrashes(singlepointoffailure).
Tocommunicatewithaserverthread,theclientthreadneedstoknowthedes-
tination,identifiedbya48bitnumbercalledaport.Differentthreadsinaprocess
mayusedifferentportaddresses.Amoebaallowsseveralserverstolistenonthe
sameporttoimplementservicefail-overorloadsharing.
Theportisonlyalogical,location-independentthreadidentifier.Thereisno
bufferassociatedwithaport.Athreadcannot“accept”anewRPCwhileitis
processingthepreviousone.Anerrorissignalledtothesenderinthiscase,which
mustrepeattherequestuntilthereceivingserviceisavailableagain.Sincethereis
noindicationofthisfacttothesender,itcanonlyperiodicallyretry,wastingCPU
bandwidth.communicationandtime

MechanismsProtection3.4.5Tanenbaumemphasisesthatthecapability-basedprotectionissolelymanagedby
usercode(see[276])andthatthekernelisnotinvolved(consequentlythekernel
isnotdirectlypartoftheprotectionsystem).Thisavoidsproblemswithcentralised
capabilityverificationservicesinadistributedsystem.
AccesstoalmostallresourcesinAmoebaiscontrolledbytheuseofcryptograph-
icallyprotectedcapabilities[275,276,196].Thesehavethedisadvantagethat
secure.probabilisticallyonlyaretheyCapabilitiesformemorysegmentsspecifythebasicaccessrights(read,write,ex-
ecute)forthecontentofthesegment.Thesemanticsofthesesegmentcapabilities
iscomparabletosegmentdescriptorsinsegmentedprocessorarchitectures.Access
toI/OresourcessuchasmemorymappedI/Oareasarecontrolled,likememory
capabilities.usingresources,Accesscontroltocommunicationports(toperformanRPC)isbasedonasimpli-
fiedvariantofcapabilities,whichonlycontaintheidentifier,i.e.theportnumber.
Thesparseportnamespaceprotectsserversfromunwantedaccessattempts(al-
thoughfortoday’sstandardsthe48bitnamespaceisnotsparseenoughtopreclude
brute-forceattacks).Ifaservicerequiresnon-probabilisticprotection,additional
clientidentitychecksmustbeimplementedbytheprogrammeroftheserver.
AnotherpossibleattacktotheRPCmechanismisthatanintruderemulatesserv-
ersbybindingtothesameport.ThisissolvedinAmoebabyusingaone-way

Amoeba3.4

79

functiontotransformportnames.ServersuseasecretportnameS,fromwhich
theportnamePtobeusedbytheclientsisderived.Pispubliclyknown,butS
mustbeknownonlytoservers,whichuseittoadvertisetheirservice.
Noattempthasbeenmadetolimittheoperationsthatmaybeinvokedbysend-
ingRPCstoacertainport,sonoaccessrightsareincluded.Thismeansthatevery-
onewhoknowstheportnumberofaservicemaysendarbitraryrequeststoit,
causingatleastwastedCPUcyclesforvalidatingandauthenticatinganRPC.
Onahigherlevel,Amoebausescapabilitiestoidentifyobjectswithinaservice.
TheseRPCcapabilities(seeFigure3.1)areinterpretedsolelybytheserver.The
verylownumberofaccessrightsbitsonlyallowscoarse-grainedaccessrestrictions.

ServerPortObjectRightsCheckField
bits4882448Figure3.1:RPCcapabilityfieldsinAmoeba

AllTheaccesscapabilityrightsitselfchecksisareprotected(andhavetocryptographicallybe)implementedagainstintamperingtheserverand.Thisforging.is
inflexibleandrequiresutmostcarewhendistributingcapabilities.Therevocation
server),problembutisininprinciplepracticeeasyeverytoservicesolve(sinceeithereverycontainsRPCalotofcapabilitycodeis“justvalidatedincase”byortheit
isimpossibletomodifytheaccessconditionswithouttakingdrasticmeasuressuch
asreplacingtheimplementationoftheserver.
TheRPCcapabilityprotectionsystemlookslikeanafterthought,toestablisha
thegenericaccessmechanismchecks.Butforstilleveryservice-internalserviceobjectmustimplementreferencestheandtoaccesssomewhatchecksonunifyits
own(toimplementcapabilityrevocation).Thispartofeveryserviceisimplicitly
nearlyidenticalcode,slightlyadaptedtosuittheparticularservice.Replicated
andaccessrightssubsequentlychecks,modifiedvaryingsourceflexibilitycodeandbetweenfunctionalityservicesofanresultsinimportantinconsistentpartof
theAmoebaprotectionalsosystem.providesThisanisaUNIXsoftwareemulation,structuringhowevernightmare.unlikeMach,thisisnota
designsystemtoaim.beTgraduallyanenbaumreplacedexpectsbythatnativetheAmoebaUNIXtools.utilitiesusedtoreachausable

SummaryandDiscussionCritical3.4.6Aftermanyyearsofdevelopment,Amoebaisacollectionofinconsistentdesign
thechoices.userItlevel.firstTherejectedprotectiontheideaofmechanismcapabilities,couldthbeenmoreadoptedpowerfulithalfifit-heartedlyhadbeenat
Amoeba,implementedandinthethekernelkernel.messageSupportingexchangeobjectfunctionsinvocationsonlyshiftisanthecodeessentialtowhatpartofis
typicallygeneratedbytheinterfacedefinitionlanguagecompiler.

80Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

ThemaindesigndecisionsandfeaturesofAmoebacanbesummarisedasfollows:
a)Virtualmemoryisrejectedasbeingtooexpensiveandcomplicated,butthe
suggestedalternative,namelyusinglotsofmainmemory,islessflexibleand
utilisation.resourcehighunderinferiorb)Memoryandprocessmanagementisactuallyimplementedinthekernel,al-
thoughitlooksasifitisanormalservice.Thisimpedesflexibility,makingit
afixed,non-improvablepartofthedesign.
c)User-levelimplementationofacapabilitysystem,toavoidacentralcapability
manager.Nopredefinedcapabilitysemantics.
d)Nocontrolovercapabilitydistribution.Revocationisonlypossiblethrough
modifyingthecodeofaserver,addingfurthercustomaccesschecks.
e)TheRPCcapabilitymechanismisnotsuitableforconveyingtamper-proof
informationtoanuntrusteduserbecauseofthelimitedsignaturelength.
f)Fileservicesarebasedonimmutablefiles.Thismakestheimplementationof
moreadvancedsemanticsveryexpensive.SharingoffilesintheUNIXsense
isimpossible,sincethecapabilityforthemodifiedfileisdifferent.
g)Oversimplificationisdeclaredafeature,whichresultsinadesignthatisjust
asflexibleasrequiredforthecurrentsystemstructure,andnotextensibleto
abstractions.powerfulmore,newTheAmoebakerneliswithoutdoubtverysmall,butthiscomesataveryhigh
cost.Inmanyareasthekernelcodewasminimisedwithoutallowingusercodeto
addtheomittedfunctionality.Theprimeexampleisthesimplisticmemoryman-
agement,whichcannotbeenhancedbyuser-levelcodetoprovideareasonable
virtualmemoryimplementation.Asaresult,itisveryeasytosabotagethewhole
systembyallocatingallavailablephysicalspace.Theattackeronlyneedsaccess
tothekernelmemoryserver,whichistrivialasithasapubliclyknownport.Itis
impossibletogetcontrolovermemoryallocationexceptbyreplacingthememory
serverwithanenhancedversion,butunfortunatelythisispartofthekernel.
Whatismissingisageneralfacilitytodelegatekerneloperations(e.g.memory
allocation)touser-levelcode,removingthelimitationsofthesimplistickernelim-
plementations.Ideally,thisfacilitycouldalsoprovideageneralframeworkfor
flexibleaccessrightschecks,withtheoptiontodefinearbitraryaccessrulesatrun
timeofthesystem,withoutchangingboththeclientandservercode.
Theclaimofincreasedperformancebynotusingvirtualmemoryisonlytrue
ifcontrastedtoabadlyimplementedvirtualmemorysystemthatpagesoutdata
thatwillsoonbeneededagain.Otherwisethereisnogain.Ontheotherhand,
evenwiththeallegedlycheapmemoryitwouldbepreferabletohandletemporary
memoryshortagesgracefully.Manyothersystemsactuallyimplementthisand
continueuntiltheworkingsetnolongerfitsinphysicalmemory.

PasswordMonash3.5SystemCapability

3.5MonashPasswordCapabilitySystem

81

TheknownMonashshortPnameasswordforit)CapabilityconsistsofSystemacustom(abbreviatedmulti-processorasMPCS,assystemthere(theisnoMonashwell-
wordMultiprocessorcapabilities[221])[14,13].andanTheoperatingprojectwassysteminspiredbasedbyontheprotectionMONADSthroughproject,pass-and
hassimilarbasicideasbutusesadifferentimplementationapproach.Theproblems
thatMONADS:neededtotobeprovidesolvedasecurewerebasisdissimilar,suitablebuttheforlargeultimatesoftwaregoalwassystems.thesameThereaswithare
similaritiestotheMONADS-Iimplementation,butastheMONADSprojectrevised
andhardwareclarifiedaspectsitswillstrategybe,themostlytwoignoredprojectsinthedevelopedfollowingindifferentdescription,directions.althoughThethe
MonashMultiprocessordesigncontainsmanyinteresting,unusualconcepts.
givenThetheimpactsmalltheMPCnumberShasofhadonpublicationsotheronresearchit.Severaloperatingothersystemsoperatingissurprising,systems
incorporatedthepasswordcapabilityconcept,suchasOpal[42]andMungi[105].
Recently,atMonashUniversity,asuccessorhasbeendeveloped,calledWal-
tonutthe[40],MPCS,whichbutarunsfewonarchitecturalconventionaladjustmentshardware.Itswererequiredarchitecturedueistoveryhardwaresimilar
virtualshortcomingsmemoryofthemanagement.IntelIA-32Acomparisonprocessorwitharchitecture,theMPCScanespeciallybeinfoundtheinarea[222].of

Structure3.5.1Thelargesoftwarephilosophysystems,behindthewithoutMPCSisrestrictingtoprovidethedesignmechanismsinanywaysuitable.forThereforebuildingonly
Everysimplesoftwareabstractionsunitareintheprovided,systemwithisadecomposedsingle,consistentintoseparatelyprotectionprotectedmechanism.seg-
mentscapabilities,(containingwhichcode,serveasdataoracross-segmentprocess).Thesereferencesmayandreferthetobasiseachforotherprotection.through
allThesegmentskernelandbyimplementsprovidingtheseaflexibleabstractionsbycapabilityprovidingmanagementasingleaddressmechanism.spacefor
possibleTheMPCtoSdoesimplementnotenforcemodules.theuseofEncapsulationcaninformation-hidingbeguaranteed,modules,byalthoughmakingittheis
datasegmentaccessibleonlybythecodethatcreatedit.

ManagementProcessandMemory3.5.2Thekernelimplementspersistentvirtualmemoryandprocesses.Thepersistent
whichvirtualmemoryprocessesmaycomprisesuse,allindependentprocesses,offiles,theirprograms,longevity.stacksEachandofothertheseresourcesmemory
resourcesisregardedasanobject.Everyobjectspansaconsecutiveareainvirtual
memory,inasingleaddressspace.

82Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

mappedDevicedrivershardwarecancontrolberegistersimplementedarevisiblecompletelyintheatthevirtualusermemorylevel..TheAccesstomemory-such
capabilities.throughcontrolledissegmentsations,Theandkernelsupportsdoesnotbothspecifythetheout-ofprocess-processmodelmodeltobe(throughusedbytheprovidingOSorthemessageapplic-ex-
changefacilitiestotransmitmessagesbetweenprocesses)andthein-processmodel
(byin-processprovidingoraout-ofsubroutine-process,callasthisfacility).isnotItismentionedunknowninthewhetheravailabletheOSisliterature.actually

MechanismProtection3.5.3TheMPCSintroducedtheconceptofpasswordcapabilities[12].Thespecialprop-
ertyofpasswordcapabilities(incontrasttocapabilitiesprotectedthroughsegreg-
ationorencryption)isthatcapabilitiescanbelogicallystoredascompletelyun-
protecteddata.Thissimplifiesmemorymanagement,comparedtosegregatedor
taggedcapabilitiesandsimplifiescapabilityaccess,comparedtoencryptedcapab-
ilities.Passwordcapabilitiesarecompactandcanbestoredeverywhere,including
Ofoutsidecourse,thethesystem,actualusingcontentarbitraryofarepresentations,capability,e.g.especiallywrittentheonaaccesspiecerights,ofpaperstill.
needstobeprotected.Inapasswordcapabilitysystemthisisachievedbymanaging
theaccessrightsseparatelyfromthecapabilityrepresentation(seeFigure3.2).

asswordPIdentifierUnique6464bitsFigure3.2:CapabilityrepresentationintheMonashPasswordCapabilitySystem
Theuniqueidentifierisactuallysplitintoauniquevolumeidentifierandaserial
agenumbermedia(uniquetheobjectwithinwithitsavolume).givenThecapabilityvolumeisstored.identifierThespecifiespasswordoniswhichgeneratedstor-
randomly(implementedwithahardware-basedrandomnumbergenerator[294]).
volume,Associatedcalledwiththeeachcataloguevolume.Theisacataloguetableofvalidcontainsonecapabilitiestreeofforvalidobjectsincapabilitiesthis
(seeFigure3.3)foreachobjectstoredonthevolume.

UniqueIdentifierPasswordAccessRightsOffsetLength

Figure3.3:CatalogueentryintheMonashPasswordCapabilitySystem
Thecreated.rootofNodeseachinthetreeistreethearemastercapabilitiescapabilitywiththereturnedsamewhenorthereducedobjectaccesshaspriv-been
ileges(i.e.accessrightsand/oraddressableareawithintheobject).Ondeletionof
acapabilitythewholesubtreeattachedtoitisdeleted.

SystemCapabilityPasswordMonash3.5

83

kernelTheforcataloguesecurityisnotreasons.anobjectGettingitselfaccess,but(eveninsteadisread-onlymanagedaccess)tocompletelythebycataloguethe
wouldstructurerevealinaallvalidpassword-capability-basedcapabilities.Cataloguessystem.arethemostsecurity-sensitivedata
beTheusedtoptobitwriteoftothethepasswordobject(afieldsoiscalledusedaltertoindicatecapability).whetherTheaaccesscapabilityrightsinmaya
exclusive,capabilityascananbeobjectclassifiedcannotintobethreebothacategoriesprocessand(theafirstdatatwoobject):classesaremutually

Processtherightrights:toThesesendaincludemessagethetorightsthetoprocess,controltoexecutionsuspendorofaresumeprocess,executionsuchas
andtolockaprocess(seesection3.5.4fordetailsonlocking).
Dataobjectrights:Theseincludebasicaccessrights,suchasread,writeandex-
ecute,andtherighttoextendorreducethevisiblepartoftheobject.
Generalrights:Theserepresentrightsonthecapabilityitself,suchastherightto
derivebecomingaanotherchildofcapabilitythewithoriginal),equaltheorrightlessertorightsdestroy(thethederivedcapabilitycapability(along
withcapabilitiesitsforderivatives),theobjecttheandrighttocreatesrenameanewthemastercapabilitycapability),(whichthedestroysrightallto
depositandwithdrawmoney(aconceptdescribedinsection3.5.5).

Structuringsoftwareintoinformation-hidingmodules(consistingofcodethat
implementsanabstractdatatypeandthedataonlyaccessiblebytheimplementa-
tioncode)ispossible,throughamechanismcalledsealing.
Sealingisinthefirstplaceauser-leveloperation.Thetype-managercodeofthe
abstractdatatypecreatesanewinstanceobject,containingthedata.Butthekernel
doesnotreturnthecapabilityas-is,insteadonehalfofthepasswordisencrypted
bycomputingtheexclusive-orofthecapabilityhalfandtheseal.Thesealisonly
knowntothecode(storedinanexecute-onlyobject),thereforethecontentofthe
objectcannotbeaccessedbytheuseroftheinformation-hidingmodule.
Thepairconsistingofacodeandadatacapabilityisroughlyequivalenttoa
modulecapabilityintheMONADSsystem,neglectingthesemanticaccessrights
system,whichcannotberepresentedintheMPCS.TheMPCShasnonotionof
entrypointsandcannotrestrictcalldestinationstodefinedinterfaceroutineentry
points.Thisispotentiallyabreachoftheinformation-hidingprinciple(andof
protection),becausecallingarbitrarycodeinthemodulemaycausemodifications
totheinstancedatanotintendedbythedesignerofthecode.
Withoutfurthermeasures,onlythetypemanagercodecouldperformmanage-
mentoperationsonsealedcapabilities,butthekernelsupportssealedcapabilities
incapabilitymanagementoperationsbylookinguponlyonehalfofthepassword
inthecatalogue.Fromtheotherhalfitdeterminestheseal.Thecapabilityopera-
tions(suchasderive,copyordelete)areperformedwiththeunsealedcapability,
and(ifappropriate)thereturnedcapabilityissealedwiththesameseal.

84Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Thisseemstoweakenthesystembyreducingtherequiredpasswordlengthfor
capabilityoperations.Thisisnotthecase,astheseoperationsneverreturnerrors
duetryingtotogetnon-matchingaccess(whichpasswords,checksbutthefullreturnapassword).capabilityItisthatnotwillpossiblenottoworkusewhenthe
capabilityoperationstodetermineonehalfofthepasswordandthentheotherone.
originalTheMPCSidentifierdoes,butnottheresupportisnomigrationtechnicalofreasonobjectsthattoanotherpreventsanvolume,implementation.keepingthe

Confinement3.5.4capabilities.InformationEachconfinementprocesscanhasabe63-bitimplementedlockwordthroughassociatedlockingwithofit,whichprocessescannotand
ofbetheread.originalLockingthelockwordprocess(L)andcausesthetheargumentlockwordfor(Lthe)tobeoperationsettothatthemodifiesexclusive-orthe
lockword(V):L=L⊕V.
Ifaprocessusesanaltercapability,theactualpassword(P)tobesearchedfor
inthethecurrentcataloguelockwordistheoftheexclusive-orprocessof(L):theP=Ppassword⊕L.storedinthecapability(P)and
abilitiesThereforeasusceptiblelockedtoprocessinformationmayonlyleakageusetoalterathirdcapabilitiesparty)with(theaonlypasswordkindofthatcap-is
bepartencryptedofthewiththe(untrusted)currentcodelockword.cannotbeThisusedmeanswhilethatthealterprocessiscapabilitiesexecutingthatwithcoulda
non-zeroNon-alterlockword,capabilitiesassuming(relatingthattotheread-onlyuntrustedandcodeexecute-onlycannotderiveobjects)themaystilllockword.be
used,e.g.constanttablesandlibraries.
Chargingforlockedservicesismuchmorecomplicated,asleavingtheusual
thirdchargingparty.regimeThisincanplacebesolvedwouldcreatethroughtheamulti-stepopportunityforchargingcovertschemechannelsbasedtoona
sealedcapabilities,describedindetailin[295].
stantialSettingupeffort,theasallenvironmentusablealtersothatcapabilitiesuntrustedneedcodetoisbestrictlyspeciallyconfinedprepared.isaThissub-
mechanism,however,cannotguaranteethatthecalledcodecannotarbitrarilyover-
writethedataintheobjectsforwhichitreceivesaltercapabilities.Withthispro-
tectiongranularity,onlyasubsetofconfinementproblemscanbesolved.

ManagementResource3.5.5TheMPCSalsointroducedaninterestingresourcemanagementmechanismfor
theapplicable,objectsasstoredincapabilitiesvirtualmaybememorystored.Classicaloutsidethegarbagesystem,collectionmakingtheschemesaredetermina-not
(bytionofdeletingunreachablethemasterobjectscapability)impossible.wasRelyingdeemedsolelyoninsufficient.explicitlyTodeletingremedythis,objectsa
financialapproachhasbeenchosen:eachobjecthasto“payrent”[295].

SystemCapabilityPasswordMonash3.5

85

moneyAssociated(forderivedwitheachcapabilitiescapabilitythe(i.e.availablestoredinmoneytheisthecatalogue)minimumisaofquantityitsownof
valueandthatofallitsancestors).Moneycanbewithdrawn(assumingthereis
enoughleft)anddepositedbyanyonehavingacapabilitywiththeserights.
Thekernelperiodicallychargeseveryobjectasumproportionaltoitssize,rep-
resentingthecostofstorage.Bankruptobjectsaredeemedtobegarbageandare
destroyed,andthecapabilitiesareremovedfromthecatalogue.Everyusercan
decidehowtoensurethathisimportantobjectsneverrunoutofmoney.
Moneyindirectlyplaysanimportantrolewithprotection.Thepasswordscheme
onlypassword.guaranteesHoweverthisprobabilistictypicallyprotection.needsItseveralisguesses,theoreticallyandeachpossibleaccesstoguessattemptthe
withanincorrectpasswordincursafine,whichiswithdrawnfromthemoneyof
thecurrentlyrunningprocess.Iftheprocessrunsoutofmoney,itisdeleted.
ThemoneymechanismcanalsobeusedtoformaneconomywithintheMPCS,
wheretheuseofaservicerequirespaymentofmoney.Thisworkswellforservices
thataretrustableandwherethefeecanbeimmediatelycomputedandcaptured.
Moneyiscreatedbythesystemadministrator,whomaycreatenewobjectscon-
tainingarbitraryamountsofmoney.Generallytheadministratorwouldonlydo
thisinreturnforsomeformoflegalcurrency.Theuserwillthengetthecapability
fortheobjectwhichallowshimtotransfermoneyintootherobjects.Thesystem
administratormayalsoconvertsystemfundsintorealmoney,ifauserpasseshim
acapabilitywithwithdrawalrights.Theexchangeratebetweensystemfundsand
realmoneyisdeterminedbythesystemadministrator.

SummaryandDiscussionCritical3.5.6TheMonashPasswordCapabilitySystemisanapproachtocreateasecureen-
vironmentabstractionsbasedareonactuallyasmallnosetlongeroftrulycomparablysimple,whensimplealltheabstractions.detailsoftheHowever“simple”,the
keytoabstractionsthearecomposabilitytakenintointoaccount.moreThecomplexsubtleprotectiondetailsofmanymechanisms.abstractionsarethe
Viewedfromadifferentangle,thismeansthatallhigh-levelprotectionschemes
isareactuallydirectlynotsupportedpossiblebytotheleavekernel,theboundsalthoughcreatedonlyinbyatheverybaserudimentaryabstractions.form.ThisIt
meansfunctionalitythat.theThekernelkernelinisfactneitherisnotflexiblesimple,noritisextensible.onlyreducedtotheminimum
ThekeypropertiesoftheMonashPasswordCapabilitySystemare:
a)Pprovideersistentavirtualconvenientmemoryapplicationandpersistentprogrammingprocessesmodel.inasingleEverythingaddressisstoredspace
inthepersistentvirtualmemory,thereisnoseparatefilesystem.
b)Acentralcapabilitytableisasecurityhazard,evenread-onlyaccesscom-
inapromisesdistributedtheprotectionsystem(andsystemalsoinacompletelyfast.Themulti-processorcentraltablesystem).isabottleneck

86Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

c)assumingProbabilisticareasonableprotection,butnumberdueoftothedifferentpasswordcapabilitieslengthforanthisisobject.notcritical,
d)Pdataasswordthatcanbecapabilitiesstoredarealongeasytowithhandleotherforitemsintheapplications,sameasdatatheyarestructure.normal
e)Supportforin-processandout-of-processrequiresduplicationofmechanisms.
Nokernel-definedsynchronisationprotocolforobjects.
f)ofNoandefinedabstractentrydatapointstypetointoajumpcodetosegment.arbitraryThislocationspotentiallyinthecode.allowstheclient
g)Money-basedgarbagecollectionisausefulmechanismforsystemsthatcan-
collection.garbagereference-basedusenotThemainshortcomingistheproblemwithimplementingprotectionbasedon
perabstractmoduledatafortypes.everyUsingmoduletheistooconfinementcumbersome,mechanismandtousingenforcetheaout-oftrustable-processwrap-
inefficient.unnecessarilyisapproach

Mach3.6

In1985researchersattheCarnegieMellonUniversityannouncedthattheywere
workingonasystemsoftwarekernelcalledMach[21,5,228,22]thatcansupport
avarietyofoperatingsystemenvironments.Thistriggeredthemostinfluential
changeinOSsoftwaredevelopmentinthelastdecades.
OSdesignersstartedthinkingaboutthestructureoftheirsystems,puttingmore
emphasisonportabilitytodifferentprocessorarchitecturesandhardwareplat-
forms8.TheUNIXconceptofakernelthatprovidesallthehardwareabstractions
wascarriedovertootheroperatingsystemsincludingMach.
MachinitiallywasaquiteconventionalOSkernel,incorporatingtheexperi-
ences[227]madewiththeRIGoperatingsystembytheUniversityofRochester
andlaterwithAccentatCMU.Theaimwastostructurallysimplifyoperatingsys-
tems,especiallydistributedoperatingsystems.Lateritwasredesignedwiththe
microkernel9approachinmind,reducingthekerneltoaminimalsetoffunctions.
Machrepresentsmorethantwodecadesofresearchbyseveraldifferentgroups
(originallyatCMU,butlateralsoattheUniversityofUtahand,morecommercially
oriented,bytheOpenSoftwareFoundation).Thismakesithardtodescribeinab-
solutetermswhatMachisandwantstoachieve.Thedifferentgroupshaddifferent
8Thisarchitecturescoincidesonthewiththemarket.riseRoftheeducingRISCor,evenprocessors,better,wavoidhichingincthereasedthedevelopmentnumbertimeofandprocessocostr
ofportinganoperatingsystemtoanewprocessorarchitecturedecreasesthetime-to-marketand
revenue.theincreases91989Thetheinitialmicrokernelversionof4.3Bre-implemSDUNIXentationonofMach4.3BSDwasUNIXstillpurelyimplemenasteduser-levellargelyasserviceskernewaslcode.finished.By

3.6Mach

87

aims,andallofthemreleasedatleastone“official”Machversion—whichwasat
leastslightlydifferentandthereforenotfullyexchangeablewithanyotherversion.
NotethatthereisnodirectconnectionbetweenMachandUNIX,butUNIX
theprovidedMachtheprojectimpetustoofimplementitsUNIX,development.whichItwasaconsequentlystrongwasdesignthefirstrequirementOSportedin
toitandthestandardtobemeasuredagainst.

3.6.1ProblemsIdentifiedinPreviousOperatingSystems
Insizetheoftheearlykernel1980sgrewthebeyonddeficiencieswhatofthemonolithicsoftwareOSengineeringkernelsbecamemethodsofevident.thetimeThe
bytescouldwithhandlenoeasilyappropriate(e.g.UNIXstructuringgrewfromamechanism).fewkilobytestoseveralhundredkilo-
Machpromisedtomaketheoverallsystemdesigncleanerandmoremodular,
byvices.havingItwasonlyalsoasmallexpectedtoprivilegedimprovekerneltheandaperformance,largeascollectionitwasofclaimeduser-levelthatser-the
largefeatures.monolithicThisOSfine-grainedkernelssystemincludedastructurelotofallowsoverheadahighduetoleveltheoflargecustomisabilitynumberof
andreactionrun-timetoerrorsinreplacementthesystem,oftheavoidingservicesdowntimecomprisingduethetoOS.systemThisrebootssimplifieswhenthea
componentisupgradedorreplacedwithaversionworkingcorrectly.
Ravailableeducingtothepagingkernelbysizedecreasingpotentiallythenumberincreasesofthelocked-downamountofpagesmemoryreservewhichdbyis
thecankernel.easilybeTheorganisedlargestparttobeofloadedtraditionalonkernelsdemand.(deviceDevicedriversdriversandforfiledevicessystems)not
includedinthesystemdonotconsumespaceinmainmemory.
TheMachinter-processcallmechanism(messagepassing,thebasisofthestruc-
uteturalanOSflexibility)acrosscanseveralcrossnodes.nodeMachboundaries.issimilarThistocreatesAmoebatheinthisopportunityrespect,toalthoughdistrib-
theenvisageddegreeofdistributionisdistinctlylowerthanAmoeba.Conven-
tionaloperatingsystemsprovidenetworkcommunicationmechanisms,butrarely
usethemtoimplementanOSthatitselfspansnodes.
PinvolvedortingUNIXredesigning(oranyandotherrewritingaoperatingconsiderablesystem)toportionanewoftheprocessorOScode.EveryarchitectureOS
supplierdesignedthehardwarepartindividually.Machcontainsallthenecessary
hardwaredependentcode,makingtheuser-levelOShardware-independent.
Thelargenumberofdifferentoperatingsystemsonthemarketalsocreatedthe
OSdesireforsuppliers).aneasy,Ideallysmoothasingletransitioncomputerpathshouldbetweenbethemable(oftoruncourseseveralopposedbyoperatingthe
systems,toreducethehardwarecosts.Thiscouldalsoallowapplicationsoftware
toseveralbechosenindependentwithlittleOSregardenvironmentsfortheOSonitarunssingleon.computerMach.wasdesignedtosupport
ThedevelopersofMachobservedthatmanypartsofdifferentoperatingsys-

88Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

temsarefunctionallyequivalent,andtriedtoseparatetheonerous“standard”
independentfunctionalityfrominterfacethetoaOS-specificcomputerfunctionalitysystem,.ItrelievingprovidedtheOSandeveloperabstract,fromhardware-writ-
ingtionofalow-levelkernelcodethatthatisprovidesgenerallyaveryhardware-independentdifficulttodebug.interfaceThistotransfersthetheremainderinven-
ofciple.theThisOShadalsoimplementationbeenthethataimoforiginatedJohnRintheosenberg’sUNIXworkproject[237]intoinathegeneralMONADSprin-
context,whichtheMachdeveloperswereawareof,butneveracknowledged[108].

ManagementMemory3.6.2Machfollowsthetraditionalmodelwhereeveryprocess(inMachcalledtask)has
itsareasown,betweenseparatetasks).virtualThisismemoryverysimilaraddresstospacetheUNIX(withanmodel.optiontoSingle-addresssharememoryspace
operatingsystemsarepossible,butnotmentionedintheliterature(probablybe-
causetheywerenotparticularlyattractiveonsystemswith32bitvirtualaddresses,
whichwerethenormwhenMachwaswritten).
VirtualmemoryisbydefaultcompletelymanagedbytheMachkernel[280].
Machprovidespagingonly,evenifthehardwarealsosupportssegmentation.The
heavilypagingonmechanismvirtualismemoryimplementedoperationsin(suchkernelasspace,ascopy-on-writetheIPCmessagemechanismpassingdependsand
copy-on-referencenetworkcommunication)toimproveefficiencybyavoidingcopy
operations.Thiskernelpagerisnotveryflexible(althoughadequateforoperating
systemssuchasUNIX),andcannotbechangedarun-time.
Optionallyasocalledexternalpagercouldbeimplemented,whichmanagesvir-
tualmemoryinauser-spaceservice.Thisisconsiderablymoreflexible,butincurs
ahighoverheadduetothelargenumberofmessageexchangesandtaskswitches.
AlsothereisnowayfortheMachkerneltoforceexternalpagerstofreememoryif
anotherpagerneedsspace.Theonlychoiceforthekernelis“toasknicely”.
Thevirtualmemoryisseparatedintoregions,ontowhichmemoryobjectscanbe
Muchmapped.kernelMemorycodeisobjectsrequiredtocorrespondimplementtofiles,addressandcanspacebecopyingshared(usingbetweencopy-on-tasks.
write)whenanewtaskiscreated,similartowhatUNIXdefined.

ManagementProcess3.6.3Asnicationmentionedmechanism.above,MachConsequentlyusesa,itsmessageprocesspassingmodelisparadigmout-ofas-process.itsbasiccommu-
ofAnexecutionessentialwithinpartofathesingleMachaddressprocessspace.modelThisisistheusedsupporte.g.byfortheOSmultipleemulationthreads
librarytoimplementOSactivitiesrunningconcurrentlytotheapplication.Not
havingthreadtotobeswitchactivatedtoaisdifferentinthesameaddressaddressspacereducesspace).theswitchingcost(ifthenext

Mach3.6

89

Ontheotherhand,operatingsystemsimplementationsusingMachgenerally
forswitchRPCtasksreplies.orInthreadsfactallmuchmoreapplicationsoften,thatbecausefrequentlythreadsusethefrequentlyoperatinghavetosystemwait
(whichtranslatesintomessagessenttoandfromservices)spendmuchtimeswitch-
ingthreads.Asinglemessageexchangerequires2or3Machsystemcalls(each
withacostcomparabletoahighlyoptimisedUNIXsystemcall)andtypicallyalso
InswitchesthetoMachadifferentcontextthisthreadorstatementtask.fromthePlan9overview[219]isinteresting:
“Plan9doesnotimplementlightweightprocessesexplicitly.Weare
uneasyaboutdecidingwhereonthecontinuumfromfine-grainedhard-
weshouldware-supportedprovideparallelismsupporttofortheuserusualtimesharingmultiprocessing.notionExistingofaprocessdefini-
tionsquestionsofthreadsthantheyandresolve.lightweight[5]Weprocessesprefertoseemhaveaarbitrarysingleandkindraiseofmorepro-
cessandtopermitmultipleprocessestosharetheiraddressspace.”
processorEachthreadset.Ahasaprocessorcertainisprioritypartofandcanexactlybeonerestrictedprocessortorunset.onlyThisonaallowsparticularthe
systemdesignertoselectappropriateconstraintsforthreads.Threadpriorities
andreflecttheassignmentsystemtoaload.certainThereisprocessornoexplicitsetcantaskbemigrationdynamicallysupport.changed,inorderto
thePrioritiespriorityareovertimehandled(ifasimilarlydifferenttothreadUNIX,isi.e.thescheduledkernelthentheautomaticallydecreaseddecreasespriority
isresettotheoriginalvalue).Thisalgorithmgiveseverythreada“fair”shareof
theprocessor.Otherapplicationsthatrequireschedulingbasedonfixedpriorities
arenotExplicitpossiblesynchronisationwithan(asunmodifiedopposedMachtowaitingkernel.foramessage)betweenthreads
isbasedchronisationonmutexesoperations,andbutconditionarehardtovariablesuse,onawhichlargerprovidescale.Theefficientslightestlow-levelerrorsyn-in
the(oftennon-trivial)synchronisationcodecanleadtodeadlocksorothererrors.

Communication3.6.4AnovelwaytotackledistributionwaspartoftheMachdesign:sendingmes-
sagesbetweenlocalthreadscaneasilybegeneralisedtosendingmessagesbetween
threadsondifferentcomputers.MorethanadecadeaftertheARPAwide-area
networkingproject[188,235,48,127]demonstratedtheviabilityoflarge-scale
networking,itwasattemptedtoimplementdistributedoperatingsystems.
Datatransmissionisalwaysintheformofareliable,one-waycommunication.
eachMessagesofinarbitraryMachsizeare(storedtyped.inMessagesvirtualarememory).anarbitrarilyBufferinglong(ofsequenceunspecifiedofparts,size)
isprovidedbythekernel.Lazycopying(copy-on-write)isusedtoensuredata
integrityafterthesendoperation,avoidingthecopyoperationinmanycases.

90Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

ThecommunicationendpointabstractioninMachiscalledport.Portsuseindir-
ectsynchronousaddressingbyanddefaultarean(thisincludeslocation-independentonlythetaskdeliveryofidentifiera.message,notCommunicationthatofisa
reply,becauseoftheone-waycommunication).
Communicationisgenerallyexplicit,buttheoptimisationstoavoidcopyopera-
totionstherelyreceivingtosomenodedegreeifitisonactuallyimplicitaccessed.communication.Bulkdataisonlytransmitted
TheMachinterfacegeneratorMIGrelievestheprogrammerofwritingthemar-
ueshavetoshaling/demarshalingbecopiedintocode,thebutmessagecertainbufferpartsoftobethesent.parameterManagingliststheandreturnmemoryval-for
andmessagemaybestructurespassedisonascomplex,partofasincemessageeachtopartanotherpotentiallyservice.hasadifferentlifetime
Messagestoaremotesystemactuallygothroughanetworkmessageserver,which
isalocalproxythathandlestheremotecommunicationindependently.Thisdesign
putsallthenetworkprotocolissuesinuserspace.Theperformanceofthishowever
inprovedthetokernel,bewhichunsatisfactoryisyet.anotherLaterversionsviolationofoftheMachdesignincludedgoals.thenetworkingcode

MechanismsProtection3.6.5Machwasdesignedtosimplifythedevelopmentof“standard”operatingsystems,
mitnottoandimprovereceivesecurityfunctions,.Itincludescheckingaiftheprotectiontask(i.e.mechanismallthreadsinthewithinmessagethetrans-same
containenvironmentporthaverights,thewhichsamearerights)transferredhasthetotherighttoreceiveraccessofthetheport.message.Messagescan
cessOnlyrightaissinglesenttotaskhasanotherreadtaskaccessthenthisrightsrighttoaiscertainautomaticallyport(i.e.ifremovedthefromreadtheac-
sender’sportrights).Thereisnosuchrestrictionforsendrights.LaterMachver-
aftersionsitaddedhasabeen“sendused.once”Theright,purposewhichisistoalimitsendtherightsecuritythatisriskofautomaticallycommunicatingrevoked
withuntrustedRPCdestinations,limitingthemtojustasinglereply.
Fromthedocumentation[22]itseemsthateverythreadcanrevokeeverytask’s
porttask’saccessportnamesrights,arewhichunknowncaneasilyonecanleadjusttocoverdenial-ofthewhole-serviceportattacksname(evenspace).ifthe
Portrightsareessentiallycapabilities(althoughthemajorityoftheMachliter-
atureavoidsthisnotioncompletely)withsomespecialbehaviour.Thecapabilities
arekeptinthekerneldatastructurerepresentingatask,soeachthreadinatask
canusetheportrightbyjustspecifyingtheportname(aninteger).
ilege.ItisEveryverythreaddifficulttorunningmanagewithinportataskrightshastheaccordingsametoporttherights,principleofregardlessleastwhichpriv-
intousermoreinvokedtasksthethanservice.normallyApossiblerequired.solutionThisistodestroystheartificiallysystemstructurestructure.thesystem
Thereisnoclearrelationshipbetweenusersandthreads,whichmakesaccount-

Mach3.6

91

ingusers,andsothisaccessconceptmonitoringmustbeextremelyimplementedhardtointheimplement.operatingMachsystemhasnooutsidenotiontheof
kernel.circumventable,Extremewhichcaremustgenerallybetakenintroducestomakeeventhemoreusermanagementmanagementsystemoverhead.non-
secureSeveraloperatingprojectssystemsexploredtobewaystoimplementedmakeMach(suchmoreasTsecure,rustedorMachtoallow[31],amoreB3
certifiedvariantofMach).ThemajorityofthisresearchwasdonebytheNational
withSecuritytheAgencyUniversity(NSA)ofUtahand(e.g.SecuretheDTOSComputingproject[193,Corporation210,(SCC),251,in252]).cooperation

Structure3.6.6overallStructuringsystemtheintooperatingmanageablesystembyparts.serviceMixingisagoodstructureidea.It(taskshelpsprovidingdecomposingaservice)the
withagainhardactivityto(threadscontrol.withinthetask)howeverleadstoanoverallstructurethatis
withSystemseparateservicesservers(suchasfileimplementingsystems)thingsarelikeimplementeddifferentinafilesystemsclient–serverormodel,device
betterdrivers.Rmaintainabilityemovingtheseforbothdutiesthefromkerneltheandkernelthemeans“operatingimprovedsystem”flexibilityservers.and
MachAdeviceversions.driverAccessistoconceptuallytheI/Oalsospaceaisuser-levelcontrolledbyservicegiving[91],onlyatleastcertainintaskslater
thenecessarycredentialstoaccessphysicalmemory.Thisapproachresultsinavery
canflexibleshareainterfacesingletosetofdevicedevicedrivers.driversInaandgetmulti-serveraccesstosystemallallavailableoperatinghardware.systems
temMach(discdependsdriversonetc.)aorforconsiderablethekernelnumbertoofworkdeviceproperlydrivers(atotimingbootstrapsourcetheissys-re-
quiredspecial,forwiththetheeffectscheduler).thattheyThesearedriversnotaredynamicallyincludedinreplaceablethekernel,ormakingcustomisable.them
Driversincludedinthekernelcodebasearemuchmoreefficientthannormal
devicedrivers.Thisunintendedadvantagecreatedpressuretomovemanydevice
driversintothekernel,whichisclearlyagainsttheaimsofMach.
Implementingacertainsecuritypolicyrequiresthatallservicesmustconform
tosystem.therulesAlldefinedsecurity-criticalbythedifferentservicesmust(higher-level)implementaccesstherightsuseroftheauthenticationusersintheon
codetheirown,duplicationsinceoreveryaRPCcentralisedmayoriginateauthenticationfromaservice.differentBothuser.Thisalternativesrequiresconflicteither
withItalsoaimsofturnedtheoutMachthatprojectservicesandwhichillustraterelysystemheavilyonstructuringmultithreadingproblems.(e.g.the
isGNUduetoHurda[39]wrongoperatingimplementationsystem)ofaretheincrediblysynchronisation,hardtodebug.whichmakesOftenitannearlyerror
impossibletorecreatetheerrorsituation.
SupportforseveralOSonacomputerispartofthedesignofMach,yetmostop-

92Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

eratingsystemsareportedtoMachasa“singleserver”,whichisaeuphemismfor
widelyignoringthebasicaimsofMach.Theseoperatingsystemsgenerallyassume
thattheyaretheonly“users”ofaMachkernel,eitherbymakingmodificationsand
featureenhancementstothekernelorbynotcooperatingwithothersystems,mak-
ingresourcesharingimpossible.Devicedriversoftenhaveproprietaryinterfaces,
makingthemunusablefromotheroperatingsystemsonthesamecomputer.
VeryfewoperatingsystemswereadaptedproperlytoMach.MainlytheBSD
UNIXemulatorandtheMS-DOSemulatorwrittenbyCMUresearcherscouldco-
operateproperly.Sothemulti-serverfeaturewasapromisingpartofthetheory,but
failedinpracticesimplybecauseitrequireslargestructuralchanges.Formanyex-
istingoperatingsystemsthiswouldeffectivelyrequirerewritingthemfromscratch.

SummaryandDiscussionCritical3.6.7LookingattheperformanceofoperatingsystemsimplementedontopofMach
revealscatastrophicresults:runningUNIXapplicationsintheemulationwasvery
actualinefficientwork.iftheThesystemmicrokernelcallwasoverheadinvolved.dominatesManythesystemcostcalls10.inTheUNIXUNIXdoveryemulationlittle
convertsmostsystemcallsintoatleast2messages(onerequest,onereply),which
intypicallyMachisneedmore4thanmessagethreetimesoperationsasoverall.expensiveThethaninequivalentastandardofaUNIXUNIXsystemsystem.call
Manydesignandimplementationdecisionshavebeenrevisedseveraltimes,fre-
warequentlymaintenance,changingthebutitoperatingalsocreatessystemkernelbarriersinterface.betweenThisoperatingthwartssystemssystemusingsoft-
Machastheirkernel—makingitinfeasibletorunseveraldifferentoperatingsys-
temsonasinglecomputer.
adoptedSeveralMachoperatingastheirsystemskernel.(variousOftentheUNIXsuppliervariantsandchangedrecentlytheMachAppleinterfaceMacOSorX)
implementation.EvenifMachwasleftunmodified,mostoperatingsystemsontop
ofMachassumedthattheywereinfullcontrolofthewholesystem.Thename
Machbecameamust-haveforoperatingsystems,regardlessoftechnicalmerit.
Machwasmisusedasabuzzwordanddemotedtojustaportabilityaid.
MachwantedtobeafreshstartinthespiritofUNIX,integratingmanyofthe
thenewerenditconceptsexhibitedthathavemorebeenweaknessesdevelopedthaninitstheprecursorcontext.ofItsmaindistributedpropertiessystems.andIn
are:features

a)Processorthreadswitchingdominatesoverheadforeverymessagesendand
operation.receive

b)Highfrequencyofkernelcallsleadstohighmodeswitchingoverhead.
10factorsThearetransitionsavingandbetweenrestoringuserandthetaskkernelstatemodeandiscochangingmparabletheinvirtuaMachlmemoryandUNIX.Theenvironment.maincost

3.7L4

93

c)Distributionwasadesignaim,butnotusedexceptforresearchpurposes.
d)causeMachoffailedtodependenciesreducethebetweenkernelthetoonlykerneltheandthemessagingdevicedrivers.implementation,be-
e)Thekernelinterfacechangedfrequently,whichlimitstheopportunityofrun-
ningmorethanoneoperatingsystemontopofMach.
f)Manycontroloveroperatingtheentiresystemssystem.portedtoMachassumedthattheyhaveexclusive
g)Out-of-processimplementationcreatesartificialstructuralcomplexity.
h)limitedSecurityinwasflexibilitynotaandprimepowerdesign.goal,andtheprotectionmechanismsare
doit.MachInisthetoday1990swidelywhenitconsideredwaswidelyafailure,used,oritatprovedleastfarantooexampleexpensive.hownotLaterto
themicrokernelsstructural(e.g.difficulties.L4andFluke)triedtodecreasethecostandtoavoidsomeof

L43.7Thisearlierisatypicalmicrokernelsexamplehaveofbeenalearntsecondandgenerationperformancehasmicrokernel.improvedThelessonssubstantiallyfrom.
L4otherreducedhand,itthemanagedfunctionalitytoavoidofthetheworstkernelevenfallacyofmore,manycomparedmicrokernels,toMach.namelyOntheto
reducefunctionalitywithoutdecreasingtheperformanceoverhead.
L4[177,180](anditspredecessorsL3andEumel)areinfairlywide-spread
usetoday,bothatUniversitiesandintheindustry.Thereareimplementations
forsystemsanumberavailableofonprocessortopofL4(e.g.architecturesL4Linuxand[100,thereare101],aseveralUNIXcompletecompatibleoperatingOS).
SinceL4isonlyakernel,itcannotbedirectlycomparedwithfull-featuredop-
eratingsystems.Onlythefunctionalityofthekernelcanbeanalysedandthecon-
sequencesforacompleteoperatingsystemimplementationmustbeestimated.

L4ofAims3.7.1ThesufferprimaryfromthegoalofL4performance[182]isproblemtocreateofaolderhigh-speedmicrokernels.microkernelThethatfunctionalitydoesnotof
theThekernelkernelislimitedavoidstotheimplementingabsoluteservicesminimumthatrequiredarelikelyforatobemicrokernel.enhancedorre-
kernel,implementedwhichatcantheuserthereforelevel.beThisoptimisedreducesmorethecodeaggressivelysizeand(e.g.bycomplexitywritingofthethe
language).assemblyinpartsperformance-critical

94Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Thedetailsofthekernelinterfacearedefinedtobeprocessorarchitecturespe-
cific[179].Onlythehigh-levellanguageinterfaceispreciselydefined.TheIDL
compilerusesarchitecture-specifickernelinterfacestogenerateoptimisedcode.

Structure3.7.2L4providesasmallkernel(only12KBcodesizeforL4/486,conformingtoan
olderspecification,see[181])thatprovides12portablesystemcalls(ofwhich4
arememoryprivileged)usageofwithauser-levelsetoftasks.associatedAllthedatafunctionalitystructuresthatbeyondcontrolexecutionexecutioncontroland
andsimplevirtualmemorymanagementisdelegatedtouser-levelcode.Theonly
pageconcessionfaultsisandthattheschedulingkerneldecisionsdefinesatothenumberinvolvedofprotocolsapplicationthatdeliverthreads.interrupts,
Devicedriversandfilesystemshavetobeimplementedasuser-levelservices.
VirtualThreadsmemorymaybemanagementgroupedintoisusedclansto.Wprovideithinthelimitedclans,accessallthreadsprivilegesmaytoacommu-driver.
nicatefreely,andallcommunicationwithotherclansiscontrolledbyaspecially
designatedthreadwithintheclan,calledthechief.

ManagementProcessandMemory3.7.3Thevirtualmemoryimplementationsupportsonlypaging,althoughthegrouping
ofpagescalledfpage(flexpage)usedinL4bearsastrikingresemblanceofsegments
consistingofpages,asusedinMULTICS.
Anaddressspaceisacollectionoffpages,withassociatedbasicaccessrights
(read,write,execute).L4doesnotenforceanyrelationshipbetweentasksand
addressvelopersoftenspaces.referItcantobeAngelused[197],toNemesisimplementa[171]andOpalsingle-address-space[42]).OSHowever(thethede-
securityarchitecturedescribedbelowdependsonmultipleaddressspaces.
Pspace.agesThisfromcreatesoneaaddressrecursivespacemappingmaybeoffpages,mappedorbecausegrantedthetomapanotheroperationaddressuses
virtualaddressestospecifythemappinglocationinboththesourceanddestination
addressspace.Theinitialaddressspaceσ0consistsofanidempotentmappingfrom
virtualaddressestophysicaladdresses.Grantingpagesisavariationofmapping,
whichremovesthefpagefromthesourceaddressspace.
L4implementstheout-of-processmodel.Thesingleabstractionofactivityis
calledaddressthreadspaces.,Eachregardlessthreadwhetherhasanthisassociatedreferstoscheduleractivitieswithinthreadaandsingleapagerormultiplethread.
Theschedulerthreadcontrolsexecutionofthethreadsforwhichitisresponsible
fault(e.g.adjusthandlingtheforitsprioritiesassociateddynamically).threads,e.g.Likewisetotheimplementpagerthreadcheckpointingimplements[265].page
ThedefaultIPCmechanismisageneral-purposemessagesend/receiveopera-
tion.L4implementsonlysynchronous,unbufferedcommunication.Messagesare

L43.7

95

andsentatolocallyspecificuniquethreadsone(whichwithinhaveanexactlyaddresstwospace).identifiers,Theasendergloballyblocksuniqueuntilonethe
receivingthreadacceptsthemessage(ortheoperationisabortedwithatimeout).
Messagesconsistofupto64words,whichcancontaineitheruntypeddatawords
ororcantypedmapdata.orThegranttypedfpagesdatatotheelementsreceivercan.beThereceiverreferencesmaytorefusevariable-sizedtoacceptstringsany
(i.e.typedtheredataisnoitems.ThepredefinedIPCisthemechanismonlyforkernel-providedsynchronisingsharedsynchronisationmemory).mechanism
beTheIPCimplementedmechanismatthemakesusernolevel.L4provisionsprovidesfortworemotevariantscommunication,oftheIPCbutthisoperation.can
Ahighlyspecialisedvariantreducesthecostforthecommoncase,whichcanonly
communicatewithinanaddressspaceandhasfurtherrestrictions.
asaThreadsuser-levelcanalsoservicebycommunicatesettingupthroughthreadssharedthateithermemory,sharebutanthisisaddressimplementedspaceor
bysharingfpagesbetweenseparateaddressspaces.

CommunicationandMechanismsProtection3.7.4Intheprevioussectionthegeneralformatofamessagewasdescribed.L4im-
relayingplementsmessagescommunicationtotheisolationrespectivechiefbetween[175],threadsbothforbelongingincomingtodifferentandclansoutgoingby
messages.Thechiefdecideswhetherthecommunicationislegitimateandeither
message.thesuppressesorrelaysThiscommunicationarchitecturecancontroltheflowofinformationbetween
sary).differentThisclansdesign(thereducesassumptiontheisthatoverheadwithindueatoclanaccessnoaccesschecks,checksbutthearestrictlyneces-
hierarchicalmodelcannotefficientlyrepresentarbitrarycommunicationpatterns
trolwithoutoverputtingcommunicationeverythreadtotheunderchiefsthecreatescontrolaofabottleneck,separateaschiefthe.chiefDelegatingcanhandlecon-
onlynorminonemessagesecurity-sensitiveatatime.systems,Communicationwhichintroducesbetweenmoredifferentoverheadclansthanhasatobesimplethe
buteffectivegeneralaccesscontrolsystemwouldhaverequired.
trolAthefewsstateystemofthecallsarekernel.Areservedprivilegedforprivilegedthreadmaythreadsuseallwhichsystemarecalls,allowedtoviolatingcon-
theatedtoprincipleatrusted,ofleastprivilegedprivilege.threadThethatprivilegedimplementssystemcallsfine-grainedcanofaccesscoursebechecks,deleg-but
thislevelofindirectionincreasesthecost.
checks.TheThiremainingsreducessystemthecallscostareoftheusablebulkbyofanysystemthreadatcalls,anybuttime,alsowithoutreducesaccesscon-
trolexceedingoverthethoseactivitiesalreadyintheincludedsystem.inL4isTheveryimplementationcomplicated.ofprotectionconcepts
L4providesnofurthersecuritysystemsthatsupportidentificationofusers,au-
accounting.orthentication

96Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

SummaryandDiscussionCritical3.7.5L4isaveryflexiblekernel,whichcanbeusedtoimplementoperatingsystemswith
vastlydifferentdesigns.Itsmainpropertiesare:
a)GoodIPCperformancebymakingoptimaluseoftheprocessorarchitecture.
b)Theclans-and-chiefscommunicationarchitectureintroducesabottleneck,as
allmessagesbetweenclansareredirectedtothechief,whichmustdecide
legitimate.ismessagethewhetherc)Thesuperiorthroughputandlatencybenchmarkfiguresareapplicableonly
toinsecuresystems,whichexertnocontrolovertheflowofinformation.
d)Theallowedsystemcallsathreadmayusecannotbereduced.Thislimitsthe
securityofauser-levelOSimplementation.
e)intoNotaallhierarchysoftwarewithoutsystemsandadverselyresourceaffectingmanagementdesignandproblemsefficiencycan.beforced
L4iscertainlyavastimprovementovertraditionalmicrokernels,insize,struc-
thetureotherandhandefficiencyits.InlimitationsfacttheaffectmostdirectlynotablethepropertydesignofandL4isthesecurityspeedoftheofIPC.OSim-On
thisplementation.requirestailoringWhileittheispossibledesigntospecificallyimplementtoL4veryandsecurecreatessystemsaccessonchecktopofover-L4,
headsImplementingthatcanaeasilyUNIX-likeoutweighsystemthehoweverperformanceispossiblegaininaachievedverybythelightweightefficientfashion,IPC.
becauseofitssimpleandlimitedprotectionmodel.

Grasshopper3.8Grasshopperisanattempttobringtheworldsofpersistentprogramminglanguages
andoperatingsystemstogether[51,52,53].Thedesignandaimsaresimilarto,
butnotidenticalwithMONADS(someoftheresearcherswerepreviouslyactivein
theMONADSproject).ItisajointprojectofseveralresearchgroupsinAustralia,
initiallyattheUniversitiesofAdelaide,SydneyandNewcastle.
Itreconsidersmanydesignandimplementationdecisions,makingadjustments
toarriveatamoreconsistentdesignthatincorporatesmanyresultsfrompersistent
programminglanguageandOSresearch.Itintendstoprovidemorefunctionality
withlesseffort,comparedwithMONADS.

GrasshopperofAims3.8.1ThemostimportantaimistoconstructanOSthatsupportsorthogonalpersistence.
jectThetwomaymostpersistasimportantlongasitprinciplesisrequiredbehindandthatorthogonalallobjectspersistencemayarebethatmanipulatedanyob-

Grasshopper3.8

97

intheGrasshoppersamewaymust,alsoregardlessprovideoftheirlocationlongevity.independence.BeingdesignedObjectsasmayabedistributedaccessedOS,in
thesameGrasshopperway,hasregardlessbeenofdesignedtheirforactualconventionalstoragelocation.processorarchitectures,toover-
comethesinglemostannoyingproblemofMONADS,namelythecustomcomputer
witharchitecture.theDECThisAlphabecameprocessor,possiblereleased(providing1991.alargeenoughvirtualaddressspace)
wareTomakefailures,thesystememphasissuitablewasputforonoperationresilience.intheAsapresenceconsequenceofhardwareofandorthogonalsoft-
persistence,itwasdefinedthattheresiliencemechanismthatprovidesastable
storeProtectionshouldofnotbedatavisiblemustatalsothebeuserensured,level.toprotectdatafromaccidentalorma-
liciousmisuse.TheOSisdesignedtobelanguage-independent,allowingcodeto
bewritteninlanguagesthatarenottypesafe.Theprotectionsystemtherefore
cannotresponsiblerelyonfortypecheckingchecksaccessperformedrights.Itbywasthedecidedcompiler.thatInsteadtheretheshouldOSbekernelonlyais
singleprotectionmechanismforaccessestodataandOSfunctions.

Structure3.8.2theGrasshoppersystem(exceptdefinesthetwokernel):maincontainersabstractions,forwhichstorageareandthelocibasisforforallexecution.aspectsof
addressContainersspacesareandthefileonlysystems.storageContainersabstraction.andTheylociarearepersistentorthogonalandconcepts.replacebothThe
them.systemAconsistslocuscanofaonlynumberaddressofthecontainersdatainitswhichcurrentmayhosthavelocicontainer.executingContainerswithin
areLocimanagedarethebyonlythekernelabstractionunderoftheactivitycontrol.Inofitsuser-levelsimplestcode.form,alocusissimply
thecontentoftheregistersofthevirtualprocessor.Lociarecloselyrelatedto
lightweightprocessesorthreadsinmanyotheroperatingsystem.Lociaremanaged
bylocithepersistent,kernel.aTheprerequisiteGrasshopperforkernelorthogonalispersistentpersistence.[186].Thisimplicitlymakes
ulesDeviceaccessdriversdevicearedriversultimatelyonlythroughimplementeduser-levelinthekernel,modulesyetwhichmostprovideuser-levelamoremod-
secureanduser-friendlyinterface[59]todevicedrivers.

ManagementProcessandMemory3.8.3Becausealocuscanonlyaccessdatastoredinthecontainerinwhichitexecutes,
theremustbemechanismstotransferdatabetweencontainersand/ortotransfer
theexecutionrepresentedbyalocusbetweencontainers.
oneContainercontainerismappingallowedallowstoappeardatatobe(eithersharedasread-onlybetweenorcontainers.read-write)Ainregionanotherof

98Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

container.Thismechanismprovidessharedmemoryandsharedlibrariesinavery
similarwaytoconventionaloperatingsystems.
However,inGrasshopper,thecontainermappingscanbearbitrarily(thisincludes
recursively)composed.Theonlyrestrictionisthatmappingsmustnotbecircular,
toensurethatonecontainerisalwaysultimatelyresponsiblefordata.Thesource
anddestinationaddressesofamappingmaydiffer.Havingdifferentaddresses
forasingledatastructurevisibleinseveralcontainersmakesitimpossibletouse
pointersdirectly(cf.MULTICS).
Alocusmayhaveprivatedatavisibleonlytoitandinvisibletootherlocithat
executeinthesamecontainer.Thisiscalledaprivatemappingandisgenerally
usedtoalloweachlocustohaveitsownstackspace.Thissimplifiesimplementing
threadsinasecurefashion,butmakesmemorymanagementmorecomplicated.
Thesecondmechanismtotransferdatabetweencontainersiscontainerinvoc-
ation.Alocusmayinvokeacontainer,whichmeansthatitchangesitshostcon-
tainer.Everycontainerhasasingleentrypoint,calledinvocationpoint.Thesingle
invocationpointisimportantforsecurity.
Thenewhostcontainercontrolstheexecutionofthelocusandprovidesthecode
thatwillbeexecuted.Thelocusmayspecifyaparameterblockwiththeinvocation,
whichismadeavailableafterinvokingthecontainer.However,thisonlyallows
normaldatatobepassed.Capabilitiesmaybepassedthroughthecapabilitytable
whichisassociatedwitheachlocus(seesection3.8.4).
Thekernelmaintainsacallchainoftheinvocationsperformed,foreachlocus.A
locusmayspecifythatitwillneverreturntoitsprevioushostcontainer,andthen
noentryisinsertedinthecallchain.Accesstooperatingsystemfunctionsisalso
onlypossiblethroughinvocation.Eventhekernelisrepresentedbyacontainer.
Thereisnovisibledistinctionbetweensystemanduserfunctions.
Emphasisisputonorthogonalpersistence,whichrequirescreatingconsistent
snapshots(orcheckpoints).Creatingconsistentsnapshots[289,185,54]ofadis-
tributedsystemisnottrivialandinvolvesdeterminingcausalrelationshipsbetween
accessestothedistributedvirtualmemory.
Virtualmemorymanagementispartiallyimplementedattheuserlevel,outside
thekernel[183,242],bycontainersthatmanageothercontainers.Thisseparates
aparticularpagingpolicyfromtheunderlyingmechanism.Howeverthecodethat
determinestherelationshipbetweenaccessesispartofthekernel,becauseonly
thekernelknowstheglobaldependencies.Overall,resolvingapagefaultisavery
expensiveoperation,involvingseveralswitchesbetweenkernelandusermode.
Coherencybetweenthe“virtualmemorycaches”(i.e.themainmemoryused
forpaging)oftheindividualnodesiseasilyobtainedbyamultiple-reader/single-
writerprotocol,whereeithermultipleread-onlycopiesorasingleread-writepage
system.entiretheinexistsGrasshopperimplementsthein-processmodel.Alloperatingsystemfunctions
areexecutedinthecontextofthecaller.Nomessage-basedcommunicationmech-
anismsareprovidedbytheOS,butcanbeimplementedattheuserlevel,basedon
asharedcontainerthatimplementsamessageexchangeservice.

Grasshopper3.8

99

MechanismProtection3.8.4ProtectioninGrasshopperisbasedoncapabilities.ThecapabilitiesinGrasshop-
perwhichconsistentityofthisfivefields,capabilityasgrantsshowninaccess.FigureThe3.4.categoryThefielduniqueindicatesnamethespecifies“type”to
ofentityrepresented.Thisincludescontainers,locianddevicedrivers,butfurther
categoriescouldbeaddediftheneedarises.

UniqueNameCategoryRightsCapabilityRightsCategoryRightsEntity

Figure3.4:CapabilitystructureinGrasshopper

rightsThelastspecifythreerightsfieldsrelatingdefinetothetherightscapabilitygranteditselfbyandthethecapabilitycategory.Therightscapabilityrelate
tooperationsonaparticularentitycategory(e.g.deletingacontainer).Theentity
rightsinvocation.areTheyuninterpretedmaybebyusedtheassystemtagsandtoarerepresentpassedaasansimpleimplicittypesystem,parameterasanon
identifiertodistinguishbetweenlogicalobjectswithinacontainerorassemantic
accessrights.Foranin-depthdiscussionoftheaccessrightssystem,see[53].
Grasshopperimplementssegregatedcapabilities.Themainreasonisthatthis
allowsglobalgarbagecollectiontobeimplemented,asthekernelmayknowhow
manycapabilitiesexistforanentity.
groupAssociatedtableandwithcapabilityeachtablecontainer.Bothorlocustablesarearetwoprotectedtables,fromcalledusertheaccesspermissionand
maintainedcapabilities.bytheCapabilitieskernel,(hereprovidingrepresentedonlyasaoperationspairthatcomprisedguaranteebytheintegrityuniqueofnamethe
inandtheareferencecapabilitytotabletheassociatedpermissionwithgroupatablecontainerintheorlocus.namedThecontainer)permissionaregroupstored
rights.accessthecontainstableabilityLociusereferencethe.capabilitiesCapabilityownedreferencesbyarethemselvesnotprotectedthroughbythethepresentationsystem.Thisofadoescap-
notpropriatelyconstituteaprotected.securityriskCapabilitysinceonlyreferencesthearecapabilitiesinterpretedthemselvesbylookingneeduptothebese-ap-
lectedentryinthecapabilitytableofthecurrentlocusoritshostcontainerand,
assumingthereisamatch,lookinguptheaccessrightsinthepermissiongroup
tableofthecontainernamedinthecapability.
canThebekernelsupplementeditselfbyprovidesmoreonlycomplexthissimplenamingnamingschemesschemeattheforuserlevel,capabilities,e.g.tobutim-it
ally,plementstoringahierarchicalpermissionnaminggroupswithschemethesimilarobjecttoallowsthataccessprovidedrightsbytoUNIX.beAddition-changed
morecapabilityeasily,systeme.g.toisablendimplementofcapabilitycapabilitylistsrevocation.andaccessEssentiallycontrol,thelists.Infact,Grasshopperthe
dominant.areACLsofproperties

100Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Synchronisation3.8.5Synchronisationbetweenprocesses(loci)isnotexplicitlysupportedbytheker-
thenel.blockandSynchronisationunblockmechanismsoperationsonmustloci.beTheseimplementedlow-levelatthescheduleruserlevel,functionsbasedareon
sufficienttoimplementarbitrarysynchronisationprotocols,e.g.semaphores.
Besidestransactionsexplicitthatisusedinsynchronisation,creatingthecheckpoints.kernelThisimplementsisaespeciallysimplifiedimportantvariantinofa
mit,distributedasknownsystem,fromwheredatabasecreatingmanagementaconsistentsystems.snapshotrequiresa2-phasecom-

SummaryandDiscussionCritical3.8.6ThebasicstructureofGrasshopperissimplerthanMONADS,asitsupportsfewer
abstractions.ThemainproblemsinGrasshopperare:

a)thatEventhelargerwholeandvirtualmorememorycomplexkernelimplementationthanisMONADSintheduekernel.totheapproach
b)Pentingersistentthekernelprogressishardofatocheckpoint.implement,Assincethisitchangesmaintainsduringinformationcheckpointingrepres-
andbecomesirrelevantonceitiscompleted,itmakesthecheckpointingim-
complicated.plementationc)Theoptionaldelegationofpagingtouser-levelmanagersrequiresfrequent
andheadmultiplewithoutswitchesstructuralbetweenbenefitsforkerneltheandkernel.usermode,increasingtheover-
d)Parameterpassingworksdifferentlyforcapabilitiesandnormaldata.
e)atedCapabilitiesmanagementareactuallyoverheadACLsforwithdifferingprotectedpermissionobjectgroups.identifiers,withassoci-
f)ersGarbageareaccessiblecollectionatallusingtimes.referenceThiscountingexcludesonlyremovableworksmedia.reliablyifallcontain-

GrasshopperisinmanyrespectsanimprovementoverMONADS.Inothersit
onlyillustratestheproblemslatentlypresentinMONADSmoreclearly.Itsdesign
favoursplacingmuchfunctionalityinthekernel,whichasaresultbecametoo
bigtoremaineasilyunderstandableandverifiable.Itsharesthisproblemwith
manyotheroperatingsystemsthatuseamonolithickernelapproach.Thesoftware
structuringtechniquesthatsimplifythedesignareonlyapplicabletouser-level
modules,whilethekernelisanamorphousmassofcode.
Thiswascriticised[114]byHulseandDearle,twooftheGrasshopperresearch-
ers.Unfortunatelytheproposedsuccessorproject,Charm,onlyreachedthestage
whereaminimal,incompletekernelwasimplemented,andwasthenabandoned.

Mungi3.9

101

Mungi3.9Aprospectsresearchof64groupbitattheprocessorUniversityarchitecturesofNewasSouththeyWalesbecamebegantocommerciallyexploretheavailable.new
Beforethe1990ssimilarlylargevirtualmemoryspaceswereonlyavailablewith
customhardware(e.g.IBMSystem/38andMONADS).
tentialTheyofintendedimprovedtocreatestandardanewprocessorOSdesignarchitectures,[103,291,instead105]ofthatjustmatchesimplementingthepo-
acitly“scaled-up”rejectstheversionapproachofofoneofhavingtheonecommodityaddressspaceoperatingperprocess,systems.andMungifollowsexpli-the
single-address-spaceOS(SASOS)approachthathasbeenmadepopulare.g.by
AngelMungi[197],isbasedNemesisonthe[171]conceptsandofOpalIBM[42].System/38[28,112,266],adaptingand
extendingthemasrequiredtofittheiraims.Therearealsosubstantialdifferences
betweentheSystem/38andwidelyavailable64bitprocessorarchitectureswhich
searchdemandedpaperschanges.fromtheTheMONADSMungiproject.researcherswereawareof,butignoredmostre-

MungiofAims3.9.1Thefirstaimissimplicity,providingaminimalinterfaceforeveryabstraction(vir-
tualmemory,threadsandprotection)andkeepingthestructureofabstractionsas
simpleaspossible.Complementarytothis,butreferringtotheapplicationpro-
grammer’sviewofMungi,isitsusability.
Mungiaimedtoprovideaflexible,simplesetofabstractions,whicharesuitable
tobuildarbitrary,morecomplexabstractions.Mechanismsandpoliciesarekept
separatetoallowformaximumfreedomindefiningthepolicy.ASASOSelimin-
atestheaddressspaceisolationbetweenprocesses,requiringspecialattentionto
implementingsecure,reliableandintuitiveprotectionmechanisms.
Theoverallsystemshouldhaveadequateperformanceandshouldrunonoff-
the-shelfhardware.Customhardwareisperceivedtobeanacceptance,costand
reliabilityproblem.Benchmarkingsystemsonknownhardwareiseasier.
However,comparingoperatingsystemsismuchmorecomplicatedthanrunning
asetofidenticalmicro-benchmarksonidenticalhardware.AnOSwithadifferent
designapproachhasdifferentstrengthsandweaknesses,whichmeansthatitis
eitherextremelydifficulttocomparerealisticapplicationscenarios(thebenchmark
applicationshavetobecompletelyreimplementedtomatchthedifferentsystem
structure)oronerevertstocomparingapplesandoranges.

ManagementProcessandMemory3.9.2Mungipersistentprovidesdataarepersistenttreatedvirtualuniformly.memoryTheandvirtualpersistentmemory[70,processes.72]Tformsemporaryasingleand

102Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

mainaddressmemoryspace.Vmayirtualbememoryaccessibleaddressesthroughdodifferentnothavevirtualtobememoryunique,i.e.addresses.apageAllin
virtualprocessesaddresssharethiswidthissingleusuallyaddress64bitsspace11,.possiblywithdifferentaccessrights.The
ationThenetworkvirtualtomemorytransfercanthebecontentdistributedofpagesacrosstotheseveralnodenodes,whichusingaccessesathecommunic-data.
ItisexpectedtohavethousandsofnodesinadistributedMungisystem(“build-
ingsized”distributedsystem,i.e.inaLAN).Neitherdistributionnorpersistenceis
implementedintheprototypedescribedin[291].
Virtualmemoryisstructuredintoobjects,whichareconsecutivepagesofvirtual
invalidmemory.andAccessescausetoexceptions.addressesObjectsoutsidearetheuntypedallocateddataobjectsstructures,areconsideredsimilartotothebe
filescapabilityinUNIXcangetwhichaccessconsisttoanofaobject.sequenceofbytes.Onlytheholderofasuitable
executeThesinglewithinaabstractioncertainofprotectionactivityisdomaincalled,whichthreadindefinesMungi.thepartofThreadsthealwaysvirtual
morememorythanthatoneisthread,accessibleandtoallthemodificationsthread.toaProtectionprotectiondomainsdomainmayarebevisiblesharedim-by
cheap,mediatelybecausebyallthethreadsaddressingsharingthisenvironmentprotectionneverdomain.changesThread(howeverswitchestheareaccessvery
rightschangeifaswitchtoadifferentprotectiondomainoccurs).
AllofInformation-hidingtheMungikernelmodulesarefunctionalitypossible,andadherescallingstrictlythemtodoesthenotin-processinvolveswitch-model.
ingthreadsormessagepassing.Everyapplicationcanimplementitsownmessage
passingsystemwithanarbitrarysemanticsifrequired.
Theprocessschedulerintheprototypeislimitedtowhattheschedulerofthe
L4microkernelprovides.Storagemanagement(findingoutwhichobjectsare
garbage)isimplementedwithaschemederivedfromtherentmodelusedinthe
MonashcumulatingPasswordmanygarbageCapabilityobjects,SystemallandobjectstheAmoebacreatedbybankathreadaccounts.areTobyavoiddefaultac-
objectsdeletedthatwhenshallthethreadoutliveisitsdeleted.creatorThiscanisbedeleted.implementedTwithraditionalakillgarbagelist,fromcollectionwhich
is(rightfully)rejectedasnotapplicable[104].

Structure3.9.3tion.MungiToconsistsobtainaofacompletekernelthatsystem,aimplementssetofvirtualuser-levelmemoryobjects,isprocessesrequired,andwhichprotec-e.g.
implementuserauthenticationoranameservicethatmapsfromasymbolicname
ofanframeworkobjecttodescribeditsbasein[291]addressisatan(interestinglyearlystagenotoftoadevelopment.capability).Theuser-level
1132bitTherevirtualisanaddresses.implementationoftheMungikernelfortheIntelPentiumarchitecture,withonly

Mungi3.9

103

ject’sTheMungimetadata,kernelsuchasmaintainsitsbaseaaddress,system-widelengthobjectandtable,protectionwhichcontainsinformationeach12ob-in
theformofalistof<password,accessrights>pairs.Itisnotspecifiedwhether
theobjecttableisitselfanobject.Inanycaseitmustbealsomadepersistent,and
itmustbekeptconsistentwiththepersistentvirtualmemory.
Anactiveprotectiondomain(APD)isimplementedwithaspecialobject13.An
APDcomprisesmainlyalistofcapabilities,whichrefertoobjectscontainingcap-
abilities.Thislistofcapabilitylistsdefinestheobjectswhichthethreadsrunning
withinthatAPDmayaccess.AnAPDisanabstractdatatypethatenforceskernel
controlovercapabilities.Thisviolatesthedefinitionofobjectsbeinguntyped.
Virtualmemoryisimplementedprimarilyasakernelservice.Thepager(which
hasaccesstotheobjecttableandisthushighlysecuritysensitive)ispartoftheker-
nel.Theactualpagefaultswithintheobjectarehandledexclusivelybyauser-level
pager(ULP,perobject)whichrunsinaseparateprotectiondomainfromthethread
thatcausedthepagefault.ULPsareresponsibleforimplementingpersistence.
Devicedriversareuser-levelmoduleswhichhavecontrolledaccesstothehard-
wareinterface(suchasmemorymappedI/O).InterruptsaremappedtoaPDX
call(seebelow)totheassociatedinterrupthandler.AsoftheMungidesignde-
scription[291]therewasonlyonedevicedriveroperational,fortheRS-232serial
lineinterface(andthecodeexcerptscontainsynchronisationerrors).Supportfor
furtherdevicedriverswasplanned,suchasforthePCIbusandadisccontroller,
whichwouldmakeitpossibletoactuallyimplementpersistentvirtualmemory.

CommunicationandMechanismsProtection3.9.4InaSASOSitisnecessarytofindabalancebetweenprotectionandsimplicityof
sharing.Mungiimplementsapasswordcapability-basedprotectionsystem(see
Figure3.5),protectingeachobjectwithatleastonecapability.The(unique)ad-
dressofeveryobjectisanobviouschoicefortheidentifierpartofacapability.

asswordPAddress6464bitscapabilitypasswordMungi3.5:Figure

Therecanbeseveralvalidcapabilitieswiththesameidentifier,butadifferent
password.Eachvalidpasswordconveysasetofaccessrightstotheobject.Mungi
supportsonlybasicaccessrights,namelyread,write,execute,destroyandPDX.
12Thereaccountingisalsoinformationancillary.datasuchasthecreationdate,dateoflastaccessandmodification,and
it13Thiswiththeobjectexecutecanonlyaccessberight.modifiedbythekernel.Thisisenforcedbyallowingonlycapabilitiesfor

104Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

APDXcapability(PDXmeansprotectiondomainextension)referstoaspecial
object,containinganumberandanassociatedcapabilitylist,whichcanforman
information-hidingmodulewithanarbitraryinterface(yetanothertypedobject).
TheassociatedPdxCallsystemcallinvokesthePDXmoduleinacaller-defined
subsetofthecurrentprotectiondomain,extendedwiththecapabilitylistprovided
bythePDXobject(seeFigure3.6).Theprotectiondomainstateisrestoredon
returnfromthePDX.APDXcallgivesaccesstodatathecallercannot(andtypically
mustnot)accessdirectly,e.g.devicedriversorotherprivilegedsystemservices.
currentAPDselectedsubsetPDassociated
ofcurrentAPDwithPDXobject

APDduringcallPDX

CallPDX

Figure3.6:Mungiprotectiondomainextensioncall

AcapabilitywithRWXDaccessrightsiscalledanownercapability.Theholderof
suchacapabilitycanaddordeletecapabilitiestotheobject.Thepasswordfora
capabilityisuser-specified,whichisasecurityhazard,asusersarenotoriouslybad
inselectingsecurepasswords14.HoweveritisanintegralpartoftheMungidesign.
Mungiprovidesan(optional)waytoimplementcapabilityrefinement,inspired
byasimilarmechanisminAmoeba.Thebearerofanownercapabilitydefinesthe
fullsetofrefinedcapabilitieswithpasswordsthataregeneratedfromthepassword
oftheownercapability.Afamilyofone-wayfunctionsisused,tomakesurethatthe
ownerpasswordcannotbeinferredfromthepasswordsoftherefinedcapabilities.
14TheMonashPasswordCapabilitySystemavoidedthisbygeneratingthepasswordsthrougha
[294].generatornumberrandomsecure

3.9Mungi

105

Thecomputeone-waythefunctionspasswordofareaappliedcapabilitysothatwithe.g.readtheaccess.bearerofHeaRcanWthen-capabilitypassthiscan
originalcomputedcapabilitycapabilitycannottoanbeAPDthatreconstructedonlyfromneedsthereadrestrictedaccesstocapabilitythe.object.The
quiredCapabilitiescapabilityarewhenimplicitlyanaccessvalidatedisinmade,Mungi.intheThecapabilitykernellistssearchesassociatedforthewithre-
theatingcurrentaccessAPD.rights.AThecacheofcacheisvalidationsflushedisatmaintainedregulartointervalsreducetotheensurecostofthatvalid-cap-
abilityrevocationsbecomeeffectiveeventually.Thiscanleaveprotectiondomains
temporarilyinaninconsistentstate,withaccesstopagesthathavebeenaccessed
before,revoked.butApplicationswithoutaccessaretoassumedfurthertopageshandleofthisancase.objectIttoiswhichplannedtoaccessreplacehasbeenthis
uncoordinatedcachebyanimplementationthatmakesrevocationimmediate.
EverycapabilityinanAPDmayhaveanassociatedcapabilityhandler.Itspurpose
isabouttotospeedbeupsearched.searchesinThethejobofcapabilitythehandlerlists.Itisistoaddinvokedaifvalidthecapabilitycapabilityforlisttheis
accesstothecapabilitylistitisassociatedwith.Thiscanbelimitedtooptimising
theonlyordertheofhandlercapabilitieshasaccessintheto.listThisorcaninvolvebeusedtransferringe.g.toaembodycapabilitythefrommostangeneralobject
wayofimplementingprotection,areferencemonitor[11].
Mungiprovidesafeaturenotcommonlyimplementedincapability-basedsys-
tems:accessittoancanobject.expressTomakenegativethisaccesseffectiverights(ininamostcapabilitycapability-based,whichsystemexplicitlythedenyuse
ofsuchacapabilitycouldnotbeenforced),thereisamechanismtodepositand
anylockothercapabilitiescapabilityinatotheprotectionobject.domain,wheretheyareautomaticallyfoundbefore
ectly,orCommunicationindirectlyisthroughpossibleaPDXexclusivelycall).ThethroughdesignofusingaMungisharedcontainsobjectno(eitherelementsdir-
thatwouldsuggestamessagepassingapproachattheuserlevel.
object,ThecallerofimplementingaPDXcertainobjectcanvariantsrestrictoftheconfinement,addressingbutthisisenvironmentavoluntaryoftheactiontarget
ofthecaller.Theonlywaytoenforceconfinementisthroughnegativecapabilit-
toies,butobjectstheyisapplypossible,onlybuttoonlyspecificthroughobjects.aRcapabilityulingouthandlerunwantedthat(indirect)implementsaccessthe
requiredpolicy.Itisespeciallyimportantforthecapabilityhandlertocarefully
checkdeactivatingthethecapabilitycapabilitylistshandlerassociated.withPDXobjectstopreventthethreadfrom

Authentication3.9.5Userauthenticationiscompletelyauser-levelservice.Theloginthreadasksfor
thetheuserlogintable.nameItandthenusesasksthisforanametopasswordlocatewhichtheisbasedirectlyaddressusedofastheauser’spasswordAPDtoin

106Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

formafullAPDcapability(averystronghintthatthesecurityphilosophybehind
triesMungitostartdeemsanewuser-providedthreadinthispasswordsAPD.ThisassfailsufficientliftheyAPDsecure).capabilityTheloginpasswordthreadis
Thisincorrect,andauthenticationtheloginalgorithmthreadaskshasforalmosttheallcorrectshortcomingspassword.oftheUNIXauthen-
singleticationsystem,authenticationsuchasamechanism.centralThetableonlywhichimprovementprovidesaislistthatofalltheuserspasswordandisa
thenotstoredterminalintoamimiccentralthelocation.authenticationItistrivialdialog,foranyrecordingprogramthethatpasswordshasforaccesseveryto
theuser.fullIftheloginusertableoperationisforpubliclytheuser.accessible,MungithenhastheallTtherojanHorseprerequisitescantoevenimplementperform
asecure,unquestioninglyper-userfollowstheauthenticationleadofschemeconventionalsimilartooperatingtheMONADSsystem.system,butit
trustedTheMungiuserkernelidentificationdoesnottohaveapplications.anynotionofAccountingauser,forhencespaceitusagecannotisprovidepossiblea
throughtherentcollector.Theaccountingpolicyisdefinedbyuser-levelobjects.

PropertiesImplementation3.9.6TheR4x00Mungiprocessor,butimplementationthisisnotrunspartonoftoptheofthearchitectureL4andmicrokerneljustan[71]onimplementationaMIPS
aid.InfacttheMungiprotectiondomainmodelisnottrivialtorepresentwithL4
primitives,becauseL4followstheout-of-processmodelandusesmessagepassing.
AfewtricksarerequiredtomakesurethatMungiapplicationscannotcircumvent
theprotectionmechanismsbydirectlyusingL4kernelfunctions.
IncreatedthewhenprototypeaPDXeverycallisAPDsetupperformedisandrepresentedarenotwithdestroyedanL4ontask.return.ThesetasksTheyareare
keptinacachethatallowsreuseofthetaskwhenthesameAPDisneededagain.
Thissavessomeofthecostofsettinguptheprotectionenvironment.
wasToavoidmodifiedsoinformationthatallleaks,thecommunicationL4hasclans-and-chiefstogothroughcommunicationthechief.Thearchitectureother
optionrequirewouldtwiceashavemanybeentaskstotobeencapsulatesetupeach(andtaskL4inhasaanotherfixedtask,upperbutlimitthisofwould2048
tasks)anddoubletheIPCoverhead.
L4isdeemedtobeaclosematchtotheneedsofMungiforlowerleveloperations.
Thisaddressviewspaceissetup,strange,theysincehaveapartlittlefrominL4common.beingMungiflexiblefollowsenoughatodifferentsupportprocessany
model,whichisthemainreasonofthecomplexityinmappingbetweenMungi
threadsperformanceandL4ofthetasks/threads.currentkernelItwouldprototypebewithinterestingatoreimplementationcomparethethatstructureusesandthe
in-processmodelalsoatthekernellevel.
Theimplementationdevelopersofcriticiseprotectionthatandcurrentaddresshardwaretranslation.doesnotInasupportSASOSantranslationorthogonalis

Mungi3.9

107

mentation,independentoflosingtheefficiencyaccess.rightsInacheck,simplebutMMUthehardwareimplementationforcesawithoutcombinedtagging,imple-the
TLBentrieshavetobeflushedonanythreadswitchtoadifferentprotectiondo-
main.informationTheneedsmappingtobeinformationadjusted.Ahoweverseparatewouldbeaddressstillvalid,translationonlyandtheprotectionprotection
implementationwouldmakethevirtualmemoryimplementationmoreefficient.

SummaryandDiscussionCritical3.9.7Sincedistribution,thecurrenttheremightimplementationbesomeofsubtlethedesignpersistentflawsvirtualthatmightmemorypreventdoesitnotfromsupportbe-
ingingdistributedimplementedpersistentefficiently.virtualMungiismemorysufficientlythatthedifferentexperiencetootherfromsystemsothersystemsprovid-
maynotbeapplicable.Maintainingconsistencyandpersistenceinadistributed
thatsystemalreadyisamuchoccurinharderthelocalproblem,case.andthiswilladdtotheconsistencyproblems
ThemostimportantpropertiesofMungicanbesummarisedasfollows:
a)Threadsaretheonlyabstractionofactivity.Communicationbetweenthreads
iscallsonlyfollowpossiblethethroughin-processusingmodel.sharedmemory,andallfunctionsandsystem
b)Allmemoryobjects,with(includinguniquevirtualthreads)areaddresses.storedAllinathreadsdistributedshareapersistentsingleaddressvirtual
space.Thepersistentvirtualmemorycompletelyreplacesthefilesystem.
c)inaStrongcentralprotectionobjectbasedtable,onwhichpasswordmakesiteasycapabilities.torevokeTheaccesscapabilities,rightsarebutitstoredalso
isabottleneckinthedistributedcaseandasecurityhazard.
d)Capabilitiesareimplicitlyvalidatedbythekernel,i.e.asuitablecapabilityis
capabilityautomaticallybeforeansearchedaccessforisinthemadeisprotectionrejectedasdomain.beingtooExplicitintrusive.presentingofa
e)tainentryInformation-hidingpointsintothemodulescodecanarebeusedandimplemented,bymakingbytheenforcingencapsulatedthatonlydatacer-
accessibleonlytotheassociatedcode.
f)CompatibilitywithotheroperatingsystemsisnotanaimofMungi.
MungiisapromisingattemptatimplementinganOS,withprotectionandsecur-
itybeinganintegralpartofthedesign.Somedesigndecisions(suchasthestrange
Thiscapabilityisinsharprevocationcontrastsemantics)totheputaimahighofMungi,burdenonnamelyeverytobeasapplication.easytouseas
possibletotheapplication.TheMungiapplicationprogrammer’sinterfacesome-
timesisarchitecture-specificverysimpletodetailsuseandanisveryapplicationabstract,programmerwhileothershouldaspectsnotneedrelatetocloselyknow.to

108Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Exokernel3.10

TheexokernelOSarchitecture[73]isaradicalattempttosimplifythekernelofan
OSbyreducingitsfunctionality.Howeverthisisdonedifferentlytothemicrokernel
approach,whichfocusesonmessage-passing.Theexokernelreducesthefunction-
alitymuchfurther,adoptinganevenmoreextremestylethanintheoriginalUNIX
3.1.1).section.(cfkernelThisreducedfunctionalityresultsinimprovedflexibilityandextensibility,butas
asideeffectalsosomewhatincreasedapplicationcomplexity(althoughthiscan
bealleviatedbyusinglibrariesprovidingprogrammer-friendlyabstractions).The
twosystemsimplementedusingtheexokernelapproachshowexcellentbenchmark
figures,whichprovesthattheoverheadactuallyhasbeenreduced.

Structure3.10.1Anexokerneldelegatesresourcemanagementtouser-levelcode,whichisvery
amongunusual.theTheonlyuser-levelresponsibilityprogramsinofatheprotectedkernelistomanner.multiplexThekernelhardwareprovidesresourcesno
Tomemoryachieveorprocessefficientandabstraction,securebutoperation,providestheonlyaprinciplesprotectedbehindresourcethedesignmultiplexerare:.
Separatekernelisprotectionrestrictedandtofunctionsmanagement:necessaryResourceforprotection:managementallocation,providedbyrevoca-the
tion,sharingandtrackingofownership.
Exposeavailablehardware:toaprivilegedApplicationsOS.cangetApplicationsdirecte.g.accessmaytouseallresourcesprivilegedusuallyinstructionsonly
andportedgetbyaccessthetokernelhardwarearetheDMAresourcesfacilitiesprovidedandbyinterrupts.theThehardware:resourcesphysicalex-
Thememorykernel,CPU,onlydisc,exportstranslationresourcesatlookasidethelowestbuffersandpossibleaddressinglevelrequiredcontexts.for
protection(e.g.discblocks,memorypages).
Exposeingthemallocation:controloverApplicationsabstractionallocatesemanticsspecificandresourceperformance.instancesexplicitly,giv-
Exposerevocation:Revocationofaccesstoaresourceisvisibletotheapplica-
tions.resourceThetogiveapplicationup.Athatsuitableheldaborttheresourceprotocoliscanrequiredchooseinwhichcasetheinstanceapplica-ofa
tionisnotwillingtogiveupresources.
Protecttectionisfine-grainedfine-grainedunits:(e.g.Toatreducethepagetheorcostdiscofblockresourcelevel).management,Protectingtheobjectspro-
thataremeaningfultoanapplicationeliminatestheneedforintermediate
abstractions.

Exokernel3.10

109

Exposenames:Physicalnamesareusedwhereverpossible,toavoidtheoverhead
oftranslationtovirtualnames.Physicalnamesimplicitlyconveystructural
informationthatmaybeusedbymanagementalgorithms.
Exposeinformation:Informationaboutthesystemandinformationderivedfrom
currentallocationsisexportedtotheapplications.Datastructuressuchas
listsoffreeresourcesandthecurrentTLBcontentaremadeavailabletothe
applications.Thisavoidshavinganapplicationsoftwarelayerthatcollects
globalinformation.Itwasobservedthattheinclusionofapplication-specific
datainkerneldatastructuressimplifiesimplementingresourcemanagement.
Thepolicydecisions(andgenerallyallresourcemanagement)aredelegatedto
(possiblymultiple)libraryoperatingsystems,whichprovideauser-friendlyinter-
facetotheirapplications.Thelibraryoperatingsystemcanbespecificallytailored
foraparticularapplication.Thisallowstheoverheadtobereducedtoaminimum.
Howevertheexokernelarchitecturedoesnotdirectlyspecifywhattoprotect,
howtoprotectit,whatglobalsystempoliciesareneverthelessincludedinthe
kernel,whatlevelofprotectionisimplementedorhowthekernelisorganised.
Thefollowingsectionsrelatetotheexokernelimplementationsdescribedin[73].
Theessenceoftheexokernelapproachisallowinguntrustedsoftwaretoimple-
menteverythingnotneededforimplementingprotection.

MechanismsProtection3.10.2Providingprotectioninthecontextofanexokernelmeansmultiplexingresources
betweenmutuallydistrustingapplications.Eachresourcemustbeindividuallypro-
.bindingssecurethroughtected,Asecurebindingisaprotectionmechanismthatseparatesallocationfromthe
actualresourceuse.Protectionchecksareonlyperformedatallocationtime.A
securebindingisexpressedintermsthatthekernelcanimplementefficiently.The
implementationcanbebasedonhardware(e.g.constructinganappropriatepage
tableorsettingupTLBs)orbasedonsoftwaredownloadedintothekernel.The
software-basedprotectionapproachesrelyontype-safelanguages[27],verifica-
tion,interpretationofcodeorsandboxing[292].
Itissuggestedthatthesystemshouldbeoptimisedfortheallegedlycommoncase
ofhavingmutualtrust.Itisclaimed[73]thatprotectione.g.betweenprocesses
belongingtoasingleuserisuseless:
“Forinstance,anytwoUNIXprogramsrunbythesameusercanarbit-
rarilymodifyeachothers’memorythroughthedebuggersystemcall,
ptrace.Whentwoexokernelprocessescanwriteeachothers’memory,
theirlibOSescanclearlytrusteachothernottobemalicious.”(p.23)
Whilethisargumentappliesmostlytolibraryoperatingsystems,itisactuallypart
ofthelatestexokernelimplementation,Xok.Xokimplementshierarchically-named

110Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

capabilities[189],whichareamisnomerforanextendedpermissionspecification
scheme,comparedtotheUNIXuser/group/ACLscheme.
beTheusedtoprotectionimplementmechanismasecurecanbesystem.usedtoHoweverprovideleavinghigher-levelalleffortsschemestothatimprovecan
protectiontothelibraryOSprovidesnodirectincentivetoimprovesecurity.Itis
anunclearenhancedhowmuchschemethatoverheadiswouldcomparablebetocausedabyrefinedtheuser-levelcapability-basedimplementationsystem.of

StoreersistentP3.10.3isnotMultiplexingreallyaphysicalnovelconcept,memoryasandseveralCPUhasotherprovensystemstobehaveareasonablyuser-levelsimple,memoryand
managementorCPUschedulerimplementation.
Howevertheimplementationofafilesystemisbasedonresourceallocationby
XN,multipleandlibraryprovidesfilealow-levelsystems.Thein-kernelbasestorageimplementationsystem.intheXokcontextiscalled
XNdelegatestheblockmanagementtotheindividuallibraryfilesystems,based
ontion15theanywayobservationtothatimplementtheytheneedfilethesystem.blockallocationHoweverthe(andkernelaccessneedright)stobeinforma-sure
bythattherequiringstructuraltheownershipinformationkeptmodificationsatthetobeuserlevelrepresentedisinconsistent.atype-safeThisislanguage,possible
mutablerepresentingcodeanduntrustedprotecteddeterministicdataandarefunctionsexecuted(UDF).byaUDFtrustableareassumedinterpreterto.beThusim-
itXNcanisbetheverifiedfourththatdesignthe(veryownershiplittleisknowninformationaboutisthefaithfullythreeearlierrepresented.designs),cap-
ableofimplementingafilesystemwithUNIX-likesemantics.Thisisanindication
ofation.theTheincreasedseparationofimplementationfunctionalitycomplexitybetweenoverakernelclassical(responsiblefilesystemforprotection)implement-
andenciesanduser-leveladverselycodeaffects(responsiblecodeforreadabilitymanagement).Separatingresultsinprotectioncomplexfrominterdepend-manage-
mentintheformimplementedinthecurrentexokernelsystemsleadstoincreased
protection.improvingwithoutcomplexityTheperceptionthatmultiplexingdiscsisharderthanotherresourcemanage-
filementsystemproblemsisaisveryspecificsimpletopiecetheofExokernelsoftware.Theapproach.mainInmanycomplexityotherinsaystemsUNIXthefile
systemTheisimpressiveusuallycausedbenchmarkbythefigureshighlyprovidedoptimisedinblock[73]forallocationtheCheetahscheme.webserver
(moredecreasingthanwith14timesincreasingtherequestthroughputsize)ofaBindicateSDUNIXthebasedmaximumwebgainserver,thatcanalthoughbe
OSachievedfunctions.byTheaggressivelybenefitresultsoptimisingfromtheapplicationsreducedthatarenumberhighlyofswitchesdependenttoonkernelthe
15specialThecompletemechanismtableformwithanagingoneentrythisperpersistentdisctableblockiinsthelikelykerneltooplargerovidestofitnoinmainadvantages.memory.A

Exokernel3.10

111

modeandfromthereducedcopyingoverheadfordatafromandtokernelspace.
InUNIXtheoverheadofreadingfilesandimmediatelytransmittingthedataover
thenetworkbecomesdominant,asallthedataiscopiedseveraltimes.
Itisquestionablewhetherthesystemscanbefairlycomparedinthisway.The
generalfunctionalityofaBSDUNIXsystemismuchhigherthanacustom-builtOS
thatisoptimisedforasingleapplication.TheabstractionsprovidedbyUNIXhave
acertainoverhead,andremovingthemwouldalsomakeUNIXfaster.UNIXaims
toprovideaversatilesystemforalargevarietyofapplications,whileanexokernel
specificallyfocusesonoptimisationforindividualprograms.Itisnotclearwhy
anexokernelsystemshouldperformsubstantiallybetterinageneral-purposeOS
environmentwhereitcannotbeeffectivelytunedforspecificapplications.
Thecostofimplementingapplication-specificoptimisationsisusuallyonlyac-
ceptableinmanageableprojects,e.g.inembeddedsystemswherethefunctionality
ofboththeapplicationandOSisdeterminedbythespecification.Applicationpro-
grammersdevelopingforageneral-purposeOSwithvaryingworkloadareusually
notinterestedinincludingpartialoperatingsystemsintheircode.
TheotherbenchmarksbasedonpopularUNIXutilitiesthereforeshowlessper-
formancedifference.AmixofI/O-intensiveandCPU-intensiveprogramsexecuted
atapproximatelythesamespeedasunderBSDUNIX,eveninasystemunder
substantialload.Thisactuallydemonstratesthelowoverheadoftheexokernel
approachmuchmoreclearlythantheotherbenchmarks,asBSDUNIXishighly
optimised,whiletheXokkernelisaprototype.

Synchronisation3.10.4Thesuggestedbasicsynchronisationmechanisminanexokernelisdisablingin-
terrupts.Ofcoursethisisusable,eitherdirectlyorthroughhigher-levelabstrac-
tionsprovidedbyalibraryOS,butitisunclearwhytheresultingimplementation
shouldbemoreefficientorotherwiseimprovedoveramoreuser-friendlyprimitive
providedbythescheduler(whichisuser-levelsoftwareinanexokernelsystem).
Itisstatedthatavoidinglocksinanexokernelenvironmenteliminatestheneed
totrustotherprocesses(whichmayormaynotadheretotheentryorexitprotocol
foracriticalregion).Thisobjectivecanbeachievedmuchmoreeasilythrough
abstractdatatypeswhichincludethesynchronisation.

andDiscussionCritical3.10.5SummaryInthelastyearstheideaofcheckingprotectionbysoftwareinsteadofhardware
hastrustinggainedhardwaremomentuminthe[170].contextTofrustingprotection,softwareisyetconceptuallyprotectionnotbasedondifferentsoftwarefrom
isbasedpotentiallyprotectionlessissecure,hamperedbecausebyittheisneedinherentlyforverification,modifiable.whetherThereforethisissoftware-imple-
mentedbytype-safelanguagesorrun-timechecks.

112Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Theexokernelapproachfavourssoftware-basedprotection,asitallowstheker-
neltomechanismsbeextendedonatdemand,run-time.butThisdownloadingachievescodeflexibleintotheprotectionkernelbyisstillintegratingerror-pronenew
The(especiallymostoncriticalcomplexaspectsofprocessorexokernelarchitecturessystemssuchare:astheIntelPentium).
a)Protectionconventionalisoftensystems.sacrificedThefordecisionefficiencyto,basetoachieveprotectionbetteratasimilarperformancelevelthanto
UNIXisnotasuitablemodelforambitioussecurity.
b)Theapproachprovidesnoclearrelationshiptosoftwareengineeringmethods,
leadingtoanad-hocimplementationofacomplexsoftwaresystem.
c)ationofImplementinganainappropriatesensiblefileresourcesystemprovedmultiplexingtobeverygranularity.complicated,anindic-
d)Theconcurrencysuggestedanduser-levelpossiblytolongsynchronisationschedulingmechanismlatencies.leadstoverylimited
e)PortabilityofapplicationcodebecomesamajorproblemifOSconceptsare
movedintotheapplicationtoachievesubstantialperformanceimprovements.
f)Theparesperformancehand-optimisedcomparisoncustomforsystemsexokernelwithasystemsfull-featuredisnotUNIXconvincing,version.itcom-
OS,WhilethetheexperiencesexokernelsofarapproachhavecanshownbethatusedtobuildingaconstructfullyaflexiblefunctionalandOSisefficientmuch
tomoreimplement,complicatedeventhansimplifiedonewouldvariantsexpect.ofaUNIXEspecially-stylefilepersistentsystemsystemsrequiredareseveralhard
wouldattempts.meanItcanthatbethearguedcomplexitythatofthesewhatareistheconventionallyproblemsoftheincludedlibraryintheOS,butkernelthisis
delegatedengineeringtothehooksuseristhelevel,biggestandmadeproblemevenformorethewidecomplicated.applicabilityTheoflackofexokernels.software

FlaskwithFluke3.11

TheproachFlukethatblendsmicrokernela[87],microkerneldevelopedwithvirtualatthemachineUniversityconceptsofUtah,(cf.isaDijkstranovel[61]).ap-
Thedesigngoalistomaintainmaximumperformanceinthepresenceofdeepvir-
astualthemachinebasisforanesting.varietyFlukeofexecutionprovidesonlymodelsvery[90].basicUnlikeabstractionsMach,itisandnotcananbeaimusedof
FlukeAtospecialrunfeatureexistingoftheprogramsmicrokernelunmodified,isthee.g.Flaskbysecuritysimulatingarchitecture,UNIX.asuccessor
toopingtheaconceptssecurity-enhanceddevelopedinMachthevariant)contextatofthetheDTOSUniversity[193,of210]Utah.projectFlaskwas(devel-de-

withFluke3.11Flask

113

velopedjointlywiththeUSDefenseAdvancedResearchProjectsAgency(DARPA)
(NSA).AgencySecurityNationalandAswithallmicrokernels,thisdescriptionofFlukeconcentratesontheaspects
whicharedirectconsequencesfromthekerneldesign.Inafewimportantareas
theuser-levelimplementationisalsoincludedinthedescription.

Structure3.11.1Themicrokernelconceptisamethodforstructuringasystemhorizontallyinto
servicesthatcooperatetoprovidetheOSandapplicationfunctionality.Virtual
tainmachinesvirtualareamachinemethodmayforuseastructuringlower-levelasystemvirtualandmachineitsservicesandprovidesverticallya.Arefinedcer-
servicewithfurtherabstractionstothehigher-levelvirtualmachines.
andThememorybasevirtualallocation.machineHigher-levelprovidesservicesthreads,suchasmutexes,demandconditionpagingandvariables,processIPC
managementmustbeprovidedbyapplication-levelservers.
theAllrulesprocessesforvirtualmayuseamachines.safesubsetofUnfortunatelythemachinesomeprocessorinstructionsthatarchitecturesdonotviolatedefine
Flukeunprivilegedimplementsinstructionsthisinthatanestedrevealprocessglobalarchitectureinformation.16,wheretheentirestateof
childhierarchiesprocessescanisthereforelogicallybepartmoved,ofthedeletedstateofetc.thewithoutparentdetailedprocess.knowledgeWholeprocessabout
theprocesssub-hierarchy.Allreferenceswithinaprocesssubtreemustberelative,
tohidetheglobalrelationshipbetweenvirtualmachines.
forTheaparentlow-levelprocessAPIoftothetrapthekerneliskernelcarefullyAPIcallsdesignedmadesobythatchilditisprocesses.nevernecessaryInstead,
itcallsisrefersufficient.Thisforthemakesparentdeeplytonestedretainvirtualcontrolovermachinestheobjectspossibletowhichwithoutthethesystemexpo-
nentiallyarchitectureingrowingtheFlukeoverheadkernelofnestedsupportsthe“hypervisor”followinginvocations.abstractions:Thenestedprocess
Addressspaces:Anarbitrarynumberofaddressspacesissupportedbytheker-
nel.providesMultiplenoprimitivesthreadstocanallocateruninoreachfreeaddressmemory.Itspace.howeverTheprovideslow-levelprim-API
itivestoremapavirtualaddressrangefromoneaddressspaceintoanother
addressspace,atarbitraryaddressesandpossiblywithreducedaccessrights.
Kernelobjectobjects:hasanEveryassociatedobjectintype,memoryresemblingmustabetaggedcreatedbyarchitecture.usingtheAkernel.processEachcan
invokekerneloperationsonkernelobjectsresidingonpagesmappedintoits
addressparameterspacetoabysystemprovidingcall.thevirtualmemoryaddressoftheobjectasa
16TheThisrecursivearchitecturevirtualismalsoachineusedinapproachtheJavaisOSproposedprojectasa[286,cure-all19,r287,esource20]atthemanagementUniversitystrategyof.Utah.

114Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

Threadcompletelyobjectssetup,containitbecomesthefullanthreadactive,state.independentOnceaflownewofthreadcontrol.objectFlukeis
threadsprovidesinafullchildstateprocessvisibilityat.anyAtime,parentreceivingprocessallcanrelevantstopandchildexaminestate.the

Capabilities:Allreferencesbetweenkernelobjectsarerepresentedascapabilities
managedbythekernel.Processescanstoreandmanipulateindividualcap-
abilitiesthroughreferenceobjects,whicharekernelobjectsthatholdasingle
capability.Otherobjectsmayalsocontaincapabilities,e.g.eachthreadobject
slot.spaceaddressancontainsSinceonlythekernelcanaccesstheactualcontentofacapability,theyhide
theinformationwhethertheyreferenceobjectswithinoroutsidethevirtual
machineofaclientprocess.Capabilitiesdefinethecommunicationchannels
(sharedmemoryormessagepassing)aprocessmayuse,givingtheparent
completecontroloverallcommunicationintooroutofachildprocess.

Scheduling:ThreadsThecanactkernelasprovidesschedulersonlyfortheothermostbasicthreads,dthreadonatingschedulingtheirCPUfacilitietimes.
tothesethreadsaccordingtoanarbitraryschedulingpolicy.Thesethreads
canthenfurtherpartitionCPUtimeamonganothersetofthreads,forminga
schedulinghierarchy[86].Theschedulinghierarchyusuallycorrespondsto
thenestedprocesshierarchy,butisnotrequiredtodoso.

virtualThemachinehierarchicalmodelnaturethatofcanmanybearbitrarilyabstractionsnested.isneededtoprovideaconsistent

ManagementMemoryandProcess3.11.2Likeprocessallmodel,microkernelsusingbasedmessageonpassingmessagetopassing,communicateFlukebetweenimplementsthreads.theout-ofAltern--
atively,threadsmayalsocommunicatethroughsharedmemory.
Theconsistentout-of-processapproachinFlukeissurprising,becauseafewyears
earlierreplacingtwotheoftheout-ofmain-processresearchersapproachpublishedwithanapaperin-process[85]thatapproachstrongly(althoughadvocatedstill
ancemessage-based).improvement,Theirreducedreasoningsystemiscomplexityconsistent,andandjustifiesincreasedtheclaimedfunctionality.perform-They
identifiedmentationofthevaryingpotentialforaccountingaccuratepolicies,resourceincludingaccounting,per-usersuitableaccounting.foreasyimple-
wardsNoneandofthisneverisreflectedpublishedinanythingFluke.Thethatauthorsdirectlynevernegatedreferredthetopreviousthispaperclaims.after-
Thebasevirtualmachineoperateswithphysicalmemory,butthekernelsupports
mappingphysicalmemorytoadifferentlogicaladdresswithinanaddressspace.
Onepagingorormoredistributedvirtualmachinessharedmaymemory.implementtruevirtualmemory,suchasdemand

FlaskwithFluke3.11

115

Thememoryavailabletoaprocessmaybedonatedtooneofitschildprocesses,
remappingitatadifferentaddressinitsaddressspace.Theremappingmechanism
isverysimilartothatofL4andGrasshopper,andsupportsonlypage-sizedunits.
Itispossibletoimplementcheckpointingofthevirtualmemorywithoutspecial
kernelsupport.Thethreadstateisstoredcompletelyandvisiblyinthethread
object,ifthethreadisstopped.Thethreadobjectsforitschildrenarenormally
underthecontroloftheparentprocess,and,duetothehierarchicalscheduling,
stoppingthechildrenimpliesthatallthreadsinthesubtreearestopped.Atleast
oneoftheFlukepapers[87]suggestsbuildingthethreadmanagementontopof
management.memoryvirtualtheTheusuallayeringproblemwithmemoryandprocessabstractionsoccurs,be-
causeofthestricthierarchyenforcedbythekernel.Eithertheprocessmanagement
isimplemented“below”virtualmemorysothatthevirtualmemoryimplementation
canuseit,buttheprocessmanagementcannotusevirtualmemory,orprocessman-
agementisimplementedontopofthevirtualmemorylayer,butthenthevirtual
memoryhastousetheprimitivebasethreadmodel.
TheresourcemanagementinFlukeisstrictlyhierarchical,asthekernelprovides
allresources,whichcanthenbedonatedtochildprocesses.Fordifferentresources
(e.g.physicalmemory,CPUandnetworkbandwidth)differenthierarchiescanbe
used,butallresourceallocationisforcedintoatree-shapeddonationscheme.

MechanismsProtection3.11.3Flukeitselfprovidesasimple,capability-basedprotectionsystemforkernelobjects.
Themainreasonistohideinformationthatmustnotbevisible,namelywhether
thecapabilityreferstoanobjectinternalorexternaltothecurrentvirtualmachine.
Theprotectionaspectisasecondaryissue,asanythreadcanalwaysrequestthe
kerneltocreateanewcapabilityforanyofthekernelobjectsithasaccessto.
TheaimoftheFlasksecurityarchitecture[267]istoprovideaframeworkto
representandenforcediversesecuritypolicies.Itsprototypeimplementationwas
inthecontextoftheFlukemicrokernel.
ThefundamentalproblemthatFlasktriestosolveistheinherentweakness
ofsimplecapability-based(thearticlementionsHYDRA,KeyKOSandEROS)ap-
proaches:theyallowtheholderofacapabilitytocontrolthedirectpropagationof
thecapability.Usinganextralayertointerceptaccessesisconsideredinadequate,
asitexposesallabstractionsandinformationflowsthatthesecuritypolicyneeds
tocontrol.Withmanyprotectionmechanismsthisiseithernotpossibleorpolicy
flexibilitywouldlimitthedesignchoicesforthewholesystem.
Inasystemthatsupportspolicyflexibility[267,253,254,255,44],thepropaga-
tionofaccessrightsmustbecontrollableatanytime,toguaranteeconformitywith
anewpolicy.Whilemanycapability-basedsystemscanbeusedtoimplementvari-
oussecuritypolicies(cf.[128]),theycannoteasilyhandlechangestothepolicy,as
thepolicyisusuallyanintegralpartofthesystemdesign.

116Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

TheFlasksecurityarchitectureisbasedonthepresenceofareferencemonitor
thatcancontroleveryobjectinvocation.Thecapability-basedprotectionthatis
presentinFlukeisnotinitselfconsideredadequate.
anTheobjectsecuritymanagerarchitecturepart(which(seeisFigurethe3.7)referencesplitsthemonitorresponsibilitythatchecksforeverysecurityobjectinto
request)andasecurityserverpart.

Client

equestRObjectQueryServerSecurityManagerObjectPEnforcementolicyPSecurityolicy
DecisionEnforcementolicyP

Figure3.7:TheFlasksecurityarchitecture

Multipleobjectmanagers(e.g.onepersubsystem)aresupported,butthereis
onlyasinglesecurityserverthatcontainsacompleterepresentationofthepolicy.
Havingasinglerepositoryensuresconsistencyevenwhenpoliciesarechanged.
Tominimisetheperformanceimpact,theobjectmanagersmaycacheaccessde-
cisions.Thearchitectureensuresthatthecachesareinvalidatedonpolicychanges.
Objectmanagersareresponsibleforidentifyingtheobjectstheymanage,assign-
inglabelstothem.Thesecuritycontextisastring,containingtheattributesofthe
securitypolicy,suchasauseridentity,aclassificationlevelorauserrole.Security
contextsaresuitableforinterpretationbyanapplicationoruserwithanunder-
standingofthesecuritypolicy.
Usingsolelysecuritycontextsforpolicydecisionlookupswouldbeinefficient
andwouldincreasethelikelihoodofintroducingpolicy-specificlogicintotheobject
desired.notiswhichmanagers,Thesecurityidentifier(SID)isafixed-sizetypethatcanbeinterpreted(and
ofamappedSIDtoforaasecuritysecuritycontext)contextonlydoesbynotthegrantsecurityanyserver.authorisationPossessionfororthatknowledgecontext.
Whenanobjectiscreated,thesecurityserverdeterminesaSIDthatrepresents
thesecuritycontextinwhichtheobjectiscreated,accordingtothesecuritypolicy.
Usually(butthisissubjecttotherulesrepresentingthesecuritypolicy)thesecurity
contextforthenewobjectdependsonthecurrentclientobject.
IntheFlasksecurityarchitecture,theaccessrightsavailabletoanyserverobject
maydependontheuserthatcausedtherequest.Thearchitectureprovidesthe
flexibilityneededforleastprivilege,anonymityortransparentinterposition.

FlaskwithFluke3.11

117

FlaskwastakenbytheNSAasthebasisfortheimplementationofSecurity-
EnhancedLinux(SELinux),aUNIXvariantwithmuchimprovedprotectionand
security.Itisdistributedinsourcecodeform,althoughthedistributiondoesnot
containapredefined,strongsecuritypolicy.SELinuxisexpectedtobeusedin
security-sensitivesystemsinvariousUSgovernmentagencies.

3.11.4DeviceDriversandFileSystems
ToentsfromconcentratetheonOSKitthe[88,aims89],ofathecollectionproject,ofFlukedriversreusedtakenthefromdevicevariousdriveroperatingcompon-
systemsintegratedinaconsistentframework.
Theexecutiondeviceenvironmentdrivers[288]areassumptionsuser-levelontheobjects,structuretooftheminimisekerneltheandimpactitsofabstrac-their
tions.messagesE.g.tothehandlingthreadinterruptsthatwasregisteredfotranslatedraintoparticulardeliveringinterrupt.interruptAslongasnotificationanin-
terruptmessagehasnotbeenacknowledged,nofurtherinterruptnotificationsare
mitigation.interruptimplementingsent,tional,Asasidegivingeffect,accessthetofileseveralsystemstandardsupportUNIXfromfilethesystems.OSKitNowasalsoattemptsmadehaveopera-been
madecrokerneltoimprovesolution,theprovidingstateofatheartuser-levelinfilepersistentsystemstorageservice.overItthewouldbestandardpossiblemi-
tobutthisimplementhasnotbeenpersistenttried.virtualmemory(eveninadistributedsystem)withFluke,

SummaryandDiscussionCritical3.11.5TheFlasksecurityarchitectureraisesanumberofinterestingquestionsandpro-
Flukeposesaprovidessolution,thewhichnecessaryworksinaninfrastructureobject-orientedforthis,andsystemwithsimplifiesantheaccessimplement-monitor.
ationcomplexoftoFlaskasimplementthereisFlasknoinglobalotherstateoperatingvisible.systemItwouldkernels.beconsiderablymore
TheFlukemicrokernelimplementsafairlypurevariantofvirtualmachines.
Everyvirtualnestedmachines.virtualThemachineresourcesmayuserequiredthebyaabstractionsvirtualmachineprovidedhavebythetobelower-leveldonated
machines.virtuallower-levelthebyThepropertiesofthemicrokernel(includingtheFlasksecurityarchitecture)are:
a)Protectionisbasedmoreonthevisibilityofobjectsintheabstractmachines
thanonthepossessionofcapabilities.
b)Flexible,butcomplicatedandcentralisedsecuritysystem.
c)Reuseofabstractionsindisjointvirtualmachinesisnoteasilypossible.The
virtualconsequencemachines.iscodeduplicationandhavingseveralidenticallayersindisjoint

118Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

d)Basingresourcemanagementonrecursivevirtualmachinesdoesnotsupport
manyreal-worldallocationschemesefficiently,wastingresources.
e)HierarchicalCPUschedulingislessflexiblethananyglobalCPUscheduling
approach.Actuallyonlyrecursivethreaddeactivationwouldberequired.
f)Completelyuser-leveldevicedriverandfilesystemsupport.
TheFlukemicrokernelapproachisconsistentandcanbeusedtodevelopahigh-
performancesystem.Howevertherestrictiontothenestedprocessarchitecture
severelylimitstheOSandapplicationstructure.Ifitweretrulymodular,asseveral
papersclaim,onecouldimplementarbitrarystructures,asrequiredbytheproblem
athand.Obviouslythislimitationwasnotimportantinthesystemconstructedso
far,whichdemonstratedgoodbenchmarkperformance.
Itisveryinconsistenthowever,topublishawell-foundedcriticismoftheout-
of-processapproachusedinmanymicrokernelsandthentodevelopanewmi-
crokernelwithexactlythecriticisedproperties.Eitherthestatementsin[85]are
allwrongorFlukeisintentionallybasedonaninferiorarchitecture.Butthenthe
scientificbenefitofanin-depthexaminationofsuchanarchitectureisquestionable.
Infact,thetwomostinterestingaspectsofFlukeandFlaskarethedesignofthe
kernelprimitivesandtheapproachtosecurityandprotection.Boththeseaspects
actuallyhavelittletodowithmicrokernelsandthenestedprocessmodel.

RemarksConcluding3.12

Thischapterconcludesthedescriptionofthestateoftheartinthefieldofoperating
systems.Thefollowingsectionsthereforesummarisethecontentofthischapter
andtheimplicationsforanewoperatingsystemdesign.

Summary3.12.1Inpoints,thisbasedchapterlooselyseveralontheoperatinggeneralsystemsclassificationhavebeenofOSanalysedconceptsforandstrongandimplementa-weak
tionprinciplesgiveninchapter2.
Thesystemsanalysedcoverawiderangeofdesigns,rangingfromthewell-
knownUNIXsystemtoresearchoperatingsystemswithsometimesveryunusual
principlesofoperation,requiringadifferentapproachtosoftwaredevelopment.
greeTheAmoeba,UNIXL4familyandofFluke)operatingfocusessystemson(whichprovidingaincludesgeneral-purposeMachandtoacomputingcertainde-fa-
temcilityisforaassumed,widerangeprovidingofonlyapplications.limitedGenerallyprotectionatousersdiscretionaryandaccessapplications.controlCon-sys-
ventionallythesesystemshaveaseparateimplementationforthevirtualmemory
andanisms.filestore,Newerwhichsystemsrequires(suchastheL4andduplicationFluke)ofhaveprotectiontheandnecessarymanagementprerequisitesmech-for

3.12RemarksConcluding

119

theintegratingbestresultstemporarypossible,andduetopersistentarchitecturalstorage,butlimitationsthisisornotmentalalwaysselfusedto-restraint.achieve
KpersistenteyKOSonmemorythe.Itotherhashandacleanstronglyarchitecturalemphasisesmodelprotection,withsomeresourceweaknesses,controlnev-and
Theerthelessotherthisdoesnotcapability-baseddistractsystemsfromtheMONADS,essentialMonashproperties.PasswordCapabilitySys-
thetem,wideGrasshoppervariabilityandofthisMungiprotection(andtoalesserapproach.degreeMostAmoebasystemsandprovideFluke)apersistentillustrate
virtualmemoryimplementationthatreplacestheuseofseparatefilestores.This
simplifiesthesystems,buttheircomplexityisstillunexpectedlyhigh.
Theexokernelsystemdesignisanexoticapproachinspiredbythemicrokernel
whetherapproach,itisbutsuitablereducesforthelargefunctionalitysystems,asmuthechmoredifficultiesradicallyof.Sodevelopingfaritisanotfullyclearfea-
turedoperatingsystemarehigh.Itsprotectionsystemisbasedonanalternative
anismapproachtothatenhancehasthegainedkernelpopularityfunctionaliinthety,lastavoidingyears,thenamelytransitionstoprovidebetweenamech-user
modelanguagesandtokernelensuremode.protection,Oftenthisbutisthesecombinedarewiththemselvescodeverificationcomplicatedandproblems.type-safe
ingOverthefunctionalityyears,toauser-leveltendencysoftwaretowardsunits.smallAnOSkernelsexampleisistheclearlymicrokernelvisible,mov-ap-
proach,whichinitiallyintroducedmajorefficiencyproblems,causedbyincreased
carefulfrequencykernelofkerneldesigncallsandduebytofocusingtheonreducedthetrulyfunctionalityessential.Thisfunctionswasofcuredabykernel.more
Howevermicrokernelsoftenhavesecuritydeficienciesduetotheout-of-process
approach,whichmakesitunnecessarilycomplicatedtoidentifytheactualuser
theattemptingtradeofftobetweenexerciseaccesssingle-threadedrights.Theserversout-ofthat-processaresimpleapproachtoalsoimplement,introducesbut
areaperformance,performancebutarehardbottleneck,toandimplementtheandmulti-threadeddebug.serversthatprovidehigh
designs,Manyassoftwarethein-processengineeringmodelistechniquescommoncaninbemanymoreeasilyprogrammingappliedtolanguages.in-processIt
wouldmodel,bebutthispreferablehasnottoyetcombinebeenthestudiedmicrokernelthoroughlysofarphilosophy.withthein-process
SomeHavingoftheasmallanalysedkernelsystemsisbeneficialhavefairlyforlargesecurity,kernels,butisbutnotonlystrictlyaasmallprecondition.proportion
ofthemfunctionalityistorelatedtouser-levelsecurityparts.ofThistheOSindicatesortothetheopportunityapplications.fordelegatingmore

Implications3.12.2Manyoperatingsystemssofarlacksuitablestructuringconceptsforimproving
reusabilityApplicationsofOSshouldmodules,havemoreandforcontrolseparatingoverOSOSaspectsfunctionalityfrom,especiallyapplicationresourceaspects.

120Chapter3SurveyofMechanismsinExistingOperatingSystemDesigns

management.Thisalsoappliestoprotection,whichshouldbecomemoreflexible.
Itshouldbepossibletotransparentlyintroduceaccessmonitoringandreviseaccess
time.anyatdecisionsProtectionshouldplayanimportantroleinanyOS,evenifonlyasingleuseren-
vironmentisenvisaged(cf.thesecuritydisasterwithMicrosoftWindows).Thepro-
tectionsystemcanbemademorefunctionalandlessintrusiveifitismoreflexible,
creatingtheopportunityforuser-controlled,automaticaccessrightsmanagement.
Asaconsequenceoftheanalysisinthischapter,theworkingbaseforthisthesis
isamodule-basedsystemdesignthatroughlyfollowstheconceptsoftheMONADS
andGrasshoppersystems.Thesesystemsclearlydistinguishbetweenpassiveand
activeobjects,whichmanyothersystemsusingthemessage-passingmodelfailto
support.Implementingasystembasedonthein-processmodeleasilysupportsthe
largenumberofnormallyinactiveobjectsinsuchamodule-baseddesign.
PersistentmodulesareusedasthebasisfortheconstructionofboththeOSand
applications.Thisunifiestheirstructureandeliminatesthesemanticgapbetween
theOSandapplications.Thereisonlyasinglelinkingmechanismbetweenall
modules,namelyinvokingthemethodofamodule.Implementingprotectionas
partofthemethodinvocationcanachieveamuchhigherlevelofsecuritythan
protectingindividualcodeanddatasegments.Semanticoperationsareamore
appropriatebasisforsophisticatedprotectionthanbasicaccessrights.Itisusefulto
distinguishe.g.betweendifferentupdateoperationsintheaccessrightsassignment
foraparticularmethodofamoduletotheappropriatesubjects.
Processesareassumedtobegenerallypersistent.Mostprocessesrepresentuser
activity.Incombinationwiththein-processmodel,thisallowstheprocessidentity
tobeusedasthebasisforidentifyingusers.Beingabletodeterminewhichuseris
responsibleforaparticularactivitysimplifiesaccountingandauthentication.This
isakeyelementforestablishingtrust,inthesensethatapplicationscanrelyonthe
informationprovidedbythesecuritykernel.
Thecombinationofthein-processmodelandpersistentprocessesencouragesthe
responsibleuseofconcurrentactivityandminimisesthecostofprocesshandling.
TheresourceusageofprocessesintheformofmemoryandCPUtimeconsumption
motivateseconomicaluseoftheabstractionofactivityinthecomputersystem.
Ithasbeenmentionedthatthesizeofthekernelcorrelateswithitsfunctionality.
Largerkernelsgenerallyprovidemorebuilt-infunctions,buttheincreasedcode
sizeadverselyaffectsthequalityandsecurityofthekernel.Inordertoachievea
small,simplekernel,thekernelfunctionalitymustbereducedtoasfewaspossible
mechanisms,movingpolicydecisionsandnon-essentialmechanismstouser-level
code,potentiallytotrustedOSmodules.Aflexibleandextensiblekerneldesign
supportstheimplementationofoperatingsystemswithdifferentcharacteristics
purelybyimplementingtheappropriateOSmodules.
Onthisbasis,newoperatingsystemstructuringtechniqueswillbedevelopedin
chapters4and5,combiningexistingandnovelconcepts.

4Chapter

forModelObjectsBracketing

121

Mostexokernels)systemslackdescribedthefacilityintochapterdefine3access(essentiallyrightsallexceptusingarbitraryFluke/Flaskrules,andascanpossiblybe
Theexpressedincentralisedtheaccessaccessrulemonitormodel(seeconceptsectionin2.7.3).Fluke/Flaskreflectsaninstitutional-
isedarbitraryapproachaccesspopularrulesiswithalsousefulmilitaryinandothergovernmentalcontexts.WhilesecurityFluke/Flaskpolicies,butclaimsusingto
bepolicyflexible,itisactuallytailoredtowardsacentralisedsecuritymodel.The
onlyconcessionisthatitsupportsseveralcentralisedpoliciespercomputer.
Whatisneededisatrulygeneral-purpose,flexible,effectiveandefficientmech-
anismtocheckaccesspermission,goingbeyondACLsandcapabilitylists.
Enhancinganexistingaccesscontrolimplementationwithsupportfortheaccess
ruleplicatedmodelconditiononlyworsensevaluation,theproblemsupportingofmanagingarbitraryaccesspredicatesrightsandincludingrequiresaquantifiers.com-
Animplementationthatdownloadscodeintothekernelisthemoststraightforward
solutionconditionsandmaywouldbeveryfitthehighandexokernelthustheapproach.codewouldHoweverhavethetobenumberofdownloadeddifferenton
demand.Thisisquiteexpensive,evenwithanexokernel.
Achecksbettertosolutionuser-levelistocode.haveThisaavoidsmechanismthethatintrinsicsecurelylimitationsdelegatesofad-hocaccessconditionenhance-
suchmentsastoaccessACLsormonitoringcapabilitytobelists.integratedAdditionallyintoaitsingleallowsmechanism.security-relatedconcepts
Thegeneralaccesscontrolmechanism(i.e.usingACLsorcapabilitylists)ofan
checksexistingcansystembeuseddoesasanotsecondhavetolinebeofaccessscrapped.checksThethatfreelyareinvokedprogrammableonlyafteraccessthe
kernel-basedaccesschecksdeterminedthattheaccessis“permissible”.
Aoratedsuitablein2000concept,[143]ascalledabracketingprogramming,waslanguageproposedinconstruct1997in[142]theandcontextwasofelab-the
languageL1.Thisconcepthassubsequentlybeenfurtherdevelopedandrefinedin
theprogramminglanguageTimor(cf.[145,146,149,152,153,154]).Thebasic
anceidea,toasitsecurityappearsandinitsTimor,applicabilityisdescribedtoinoperatingthefirstsystempartofdesignthisarechapterthen.Itsdiscussedrelev-
inthesectionsmajor4.2topicsandofthis4.3.Thethesis.adaptionofthisconcepttotheOScontextisoneof

122

Chapter4ModelforBracketingObjects

4.1BracketingasaLanguageConcept
Inlanguagethissectionwhichthearebasicrelevantconcepttoanisoperatingpresented,systememphasisingcontext.thosefeaturesofthe

ConceptBracketingBasic4.1.1Toway(e.g.introducetosynchronisebehaviouralchangesobjects),initanmustbeobject-orientedpossibletosystemintroducedesigninchangeaingeneralthe
normallanguages)executionoftenofprovideobjects.additionalQualifyingcontextobjectsinformation(likeandadjectivestheirinmanymethodsnaturalcreate
maywell-controlledeitherbesideadditionaleffectstomethodstheorbasemayobject.beThebracketmethodsmethodsofawhichqualifyingmodifyobjectthe
interactbehaviourisoftheexistingmethodmethods.invocationThe(aspointimplementedwheree.g.bracketsbytheandtheircompiler).targetobjects
languages.BracketmethodsNormallyareaanclientextensionobjecttoinvokestheamethodmethodofinvocationtheintargetobjectobject-oriented(see
Figure4.1)andthetargeteventuallyreturnstotheclientobject.

invocationmethodClientargetTobjectobjectreturnmethod

Figure4.1:Anormalmethodinvocation
theIfatargetqualifyingmethodisobjectisredirectedassociatedtothewithappropriatethetargetbracketobject,method,thentheasinvocationillustratedinof
Figure4.2.Thisredirectionisfullyintegratedinthemethodinvocation.Neither
theclientnorthetargetneedbemodifiedorneeduseproxyobjects.

methodBracketClientinvocationmethodobject

Qualifyingobject

argetTobject

Figure4.2:Activatingabracketmethodassociatedwithatargetmethod
Replacingatargetobjectcompletelyisstraightforward,butonlyusefulinvery
targetspecialobjectcircumstances,containssuchvaluableasdataduringthattheshoulddebuggingnotbephasedestroyedofa1.system,whenthe
1Thequalifyingobjectthencontainsreplacementdatathatisusedfortestingpurposes.

4.1BracketingasaLanguageConcept

123

andInthusgeneralneedsthetoinvokequalifyingtheobjecttargetaddsmethod.aItspecificisactuallybehaviournotaspectpracticaltototheincludetarget
anormalcalltothetargetmethodinthebracketmethod,asthiswouldmake
objectsnestingofunnecessarilybracketsandthecumbersome.useofaItsinglewouldrequirequalifyingexplicitobjectformanagementdifferentoftargetthe
chainingsequenceinthecodeofthequalifyingobject.Thisfunctionalityisbetter
Toincludedmanageinthethemethodpropercallbracketprimitive,nestingwhereitsequence,needstotherebeisaimplementedspecialmethodonlyonce.call
bracket,primitiveorbodythe(seetargetFiguremethod4.3),ifbodywhichiscalleddesignatesinthethelastnestedqualifyinginvocationobject.ofthenext
methodbodypreludeobjectClientinvocationbodyinvocationmethodTobjectarget
bracketpostludereturnreturnQualifyingobject

Figure4.3:Augmentingatargetmethodwithabracketmethod
Thebodyinvocationcanbeusedanywhereinabracketmethod,includingin
conditionalstatements.Ifbodyisnotcalledthentheexecutioncannotproceed
towardsthetargetobject,effectivelydenyingaccess.Thereturnprimitiveislike-
wisemodifiedsothatitperformstheappropriatereturnofcontroltotheprevious
qualifyingobjectorultimatelytheclientobject.
Thisisthebasisrequiredtoimplementamuchmoreflexibleaccesscontrolsys-
temattheprogramminglanguagelevel.Thisisusefulwithinanapplication,but
aslongastheOSprovidesonlyalesscapableaccesscontrolsystemitbecomesa
relativelyweaklinkoftheoverallsystemsecuritychain.Itisdesirabletoadaptthe
bracketmechanism,tomakeitsuitableasanOSprotectionmechanism.
Sincetheorderingofbracketsisimportant,itisstraightforwardtorecordall
bracketsassociatedwithanobjectinabracketlist.Thislistmaybeupdatedat
run-timeasneededtointroduceordeletequalifyingobjects.
Thebracketlistobjectitselfcanofcoursebebracketedwithobjectsthate.g.
controlandmonitoraccess,providingauniform,secureandflexiblemanagement
oftheaccesscontrolsystem(orancillaryfeaturessuchassynchronisation).
Qualifyingobjectsareseparateobjects,whichcannotdirectlyaccessormodify
theinformationstoredinotherqualifyingobjectsorthetargetobject.

ExampleDefinitionBracket4.1.2Buildingreader/writeronthegeneralsynchronisationbracket[46]concept,illustratesthehowfollowingtheconceptexampleisthatintegratedimplementsinto

124

Chapter4ModelforBracketingObjects

Timormethods,.InbutFigureinstead4.4thetwobracketdefinitionofmethods,atype2oneisforshownoperationsthatanddefinesonenoforuser-visibleenquiries.
{RWsynctypeany:qualifiesopopbracketbracketop(...);enq(...);
}Figure4.4:Typedefinitionforreader/writersynchronisation
stateEveryorifitmethodqueriesinTtheimorisobjectclassifiedstate.Allaccordingmethodstothatwhethermayitmodifymodifiesthethestateobjectmust
bereadthedeclaredstatewitharethedeclaredopwithkeyword,theandenqkeyword.correspondinglyThisincludesmethodsbracketthatexclusivelymethods,
whichinthisexamplearebothdeclaredasop.
Inthetypedefinitionitispossibletodeclarebracketsforaparticularmethod(by
declaredspecifyingitseitherasname),opfororallenq.methodsThelatter(bycaseusingistheusedkeinywtheordallexample)orforinallFiguremethods4.4.
Timorsupportsacompletelyseparate,reusableimplementation,unlikemany
otherprogramminglanguageswherethesynchronisationmustbeanexplicitly
codedpartofeverymethodorsimplifiedtoalanguage-providedmechanismsuch
asThethemonitorimplementationconceptininJava,Figureusing4.5thecloselykeywordresemblesthesynchronizedway.Courtoisetal.de-
scribedthealgorithm[46]forreaderpriority.
tryThe...keywordfinallybodyconstructdenoteswhereensuresthethatbracketexceptionswillinvokecannottheleavetargetthemethod.qualifyingThe
objectstatement,inanbutinconsistentbeforethestatebracketandisisalsofinished.atrickItistohardexecutetofindcodeaaftersensiblethesyntaxreturnfor
Thereturningellipsesdatainofanthebracketunknowntype,declarationwithoutandthedeviatingbodycallarbitrarilyservefromasJava.placeholders
forpassingonanunknownandinaccessibleparameterlist.

ExampleUsageBracket4.1.3Howarequalifyingobjectsusedinprograms,giventheirdeclarationandimple-
mentation?ThesampleinFigure4.6createsasynchronisationobject3.Thisobject
isthenincludedinthelistofqualifyingobjectsforanewinstanceofThing.The
listobjectconstructionusingcurlybracketcharactersisaTimorextension,indicat-
ingaliterallist,introducedtomakecollectionconstructionlesstedious[192,77].
2Timorsupportsseveralimplementationspertype,whichcanallbeusedinasingleprogram,
withoutmisusingsubtyping.Thereforeanexplicittypedefinitionismandatory.
and3Timorobjectshasasexplicitsub-objectobjectswithinreferences,anothersimilarobject,toC+the+.useAsTofimortheasterisksupportsbothsymbolisreferencesnottooptional,objectcfs.
Figure4.5wheretheSemaphoreobjectsaresub-objects.

4.1BracketingasaLanguageConcept

{RWsyncofCourtoisEtAlimplstate:intSemaphorereadcountreaders=0;=Semaphore.init(1);
Semaphore.init(1);=mutexSemaphoreany:qualifiesopbracketreaders.p();enq(...){//thereaderbracket
ifreadcount++;(readcount==1)mutex.p();
readers.v();{try}returnfinally{body(...);
readers.p();readcount--;ifreaders.v();(readcount==0)mutex.v();

}}opbracketop(...){//thewriterbracket
mutex.p();{tryreturn(...);body{finally}mutex.v();}

}

}Figure4.5:Possibleimplementationofreader/writersynchronisation

...{Thing*RWsync*t=newsynchronised={synchronised}newRWsync.init();Thing.init();
...t.modifySomething();t.queryInteger();=i}...Figure4.6:Usingbracketstosynchroniseanobjectinstance

125

126

Chapter4ModelforBracketingObjects

Allexecutescallsthetotheappropriateobjecttwillprelude,becallsredirectedthetooriginalthemethodsynchronisationusingbodybracket,andwhichex-
ecutesthepostlude.ThemethodmodifySomethingisassumedtobeanop-
eration,whereasforquerieswhichsuchtheasbracketqueryIntegerensuresexclmayusbeiveexecutedexecutionoftheconcurrentlycritical.region,
ingTheasamequalifyingqualifyingobjectforobjectseveralcanbetargetusedforobjectscontrollingdirectlymanysupportstargetbehaviourobjects.modi-Shar-
ficationsthatcoordinatebetweentheinvocationofdifferenttargetobjects.
inTThisimor.staticThelisetupstofofaqualifyingbracketedobjectsobjectisaisoneconstantoftheinthesimplestsourcevariantscode.Theavailablecom-
pilercanoptimisethecodebyeliminatingthebracketmethodinvocationsthrough
inlining,Utilisingmakingthecodethecodestructuringasefficientopportunityascodethatwithoutdoesnotincurringuseabracketing.run-timepenalty
usesleavesofonlybracketingthepositiverequireeffectschangesoftocodethereusabilitybracketlistandofexistingreadability.objectsSomeatadvancedrun-time.
Inthecontextofprogramminglanguagesthisoccursinfrequently,andgenerally
onlydescribedforinrather[149].complicatedusesofbrackets.HowthisissupportedinTimoris

BracketsCall-Out4.1.4Forsomeapplicationsthecall-inbracketsillustratedsofararenotenough.Itcan
betargetusefulobjectalso(seetoFigureprovide4.7)call-out[153].brackets,whichcontroloutgoingcallsfroma

Clientobjectcall-inbracketTobjectargetbracketcall-out

QualifyingobjectlistbracketQualifyingobject

Figure4.7:Targetobjectwithbothcall-inandcall-outbrackets
Toavoidclutteringthediagram,thebracketlistsarenotshownasseparateob-
jectsandonlyasinglecall-inandcall-outbracketisassumed.Thedashedarrows
indicatethatbothbracketsareassociatedwiththetargetobjectshown.Call-inand
call-outbracketmethodscanbedefinedinasinglequalifier.
Call-outbracketscontrolotherobjectswhichthebracketedobjectitselfuses.
Suchbracketsaree.g.suitableforcontrollingthebehaviourofanuntrustedobject.
AreusableimplementationofHoare’smonitorsynchronisation[111]usingboth
call-inandcall-outbracketsisstraightforward,includingdeadlockavoidanceby
freeingthemonitorwhenthecriticalregionisleftbyacalltoadifferentobject.

4.1BracketingasaLanguageConcept

127

cludingThedeclarationbracketingofofcall-outspecificbrackettypes.Call-outmethodsisbracketsanalogousaretodefinedcall-ininabrackets,calloutin-
section,asinFigure4.8,wherebothacall-inandacall-outbracketispresent.

{ReleasableMutextypeany:qualifiesall(...);bracketopany:calloutall(...);bracketop}Figure4.8:TypedefinitionforasubsetofHoare’smonitorsynchronisation
Thisparticularinterfaceissuitableforsynchronisationbasedonreleasablemu-
tualexclusion,whichisasubsetofHoare’smonitorconcept.Theremovedfeatures
areThethecurrentconditionTimorvariables,definitioni.e.itisrequiresnotpossiblethattocall-outusesignalbracketsandusethewait.keyword
calltoproceedwiththenextbracket,asshowninFigure4.9.
{ReleasableMutexofReleasableMutexImplimplstate:qualifiesSemaphoreany:mutex=Semaphore.init(1);
opbracketmutex.p();all(...)//{claimsmutualexclusiononentry
{try(...)bodyreturn}finallymutex.v();{//releasesmutualexclusiononreturn
}}opcalloutbracketany:all(...){
try{mutex.v();//releasesmutualexclusiononcall-out
(...)callreturn}finallymutex.p();{//reclaimsmutualexclusionaftercall
}}

}Figure4.9:Implementationforreleasablemutualexclusion
Acall-outbracketmaynotusebodyandacall-inbracketmaynotusecall.
Thereseemstobenosubstantialdifferencebetweenthebodyandcalloperations

128

Chapter4ModelforBracketingObjects

otherbrackets.thanBothprovidingcontinueawithtextuallythenextdifferentbracketinrepresentatiothennestingfortheorder.differentkindsof
atleastCall-outonefurtherbracketingcalltoincurstheabracketsubstantialmethodrun-timeiscost,involved.asforeverybracketedcall
bracketThelistcompileriscandeclaredofcoursestatically.optimiseThethebracketcodecodeandiseliminateincludedthesebeforecallsandifafterthe
thetypicallyappropriateconsiderablymethodhigherinvocation.thaninButthethecall-inremainingcase.cost(codesizeincrease)is

4.1.5RelationshipbetweenQualifiersandTargets
Soissuefarofitwaswhatcanoutlinedbehowqualifiedbracketinghasbeenhasmostlybeenleftintegratedunmentioned.intoTimor,butthewhole
TheIthasbeenprelude/postludefoundtousefultooperationsclassifyandallenquiriesmethodsareintooftenoperationsidentical,andindependentenquiries.
ofclasstheofpreciseoperationsfunctionalitythereforeoftheeliminatesmethod.someThefurtherpossibilitycasesoftocodebracketduplication.acertainIt
allowsbracketimplementationsthatcanbeappliedtoanyobjecttype,without
evenknowingthenamesofthemethods.
Aqualifyingtypemaydefinewhichobjecttypes(anynumberispermissible)it
bemayanqualifyarbitrary,includingnumbertheofbracketpseudo-typemethodany.Fordefinitions.eachofSincethesethetypesdefinitionstheremaymay
codeoverlap,theduplicationbracketasonlymethodspecialwithcasestheneedclosesttobematchdefinedwillbeseparatelyused..Thisminimises
hasAaqualifyingreferencetotypethemayqualifieralso.haveBracketnormalmethodsmethods,cannotwhichbecaninvokedbeinvokeddirectly.ifTheyone
itsarebracketactivatedlist.onlyAonqualifieracallisatoaseparatetargetobjectobjectwhichwhichishastheindependentqualifyingoftheobjecttargetin
object(s)itqualifies,bothinitsdesignandatrun-time.
Bracketswhicharedeclaredtoqualifyaspecificobjecttypemayaccessthepara-
themeterbodylistofinvocationthemethodandinmaythemodifybrackettheprelreturnude,valuepassinathemodifiedpostlude.parameterlistto
changes,Modifyingviolatingparameterthelistsspecificationandreturnofthevaluestypeeasily(thepre-resultsandindrasticpostconditionsbehaviourare
aspartthereofistheariskofspecification).breakingChangesothertopartstheoftheparametersoftwarelistsystemmustbewhichusedarejudiciouslyunaware,
ofthespecificationchange.Howeverinsomesituationshavingfullaccesstothe
parameterlistcanbeusedconstructively.
Anyobject(includingqualifiers,butthisshallnotbeconsideredfurtherhereasit
distractsfromthegeneralprinciples)maybequalifiedbyanynumberofqualifying
notobjects,accessasthedefinedprivateinitsdataofbracketthelist.targetQualifiersobjectorareanyseparateotherqualifierobjects,.i.e.Thistheyrestrictsmay
theinteractionsbetweenobjectsandsimplifiestesting.

4.1BracketingasaLanguageConcept

129

SequencingBracket4.1.6Theorderingofbracketsissignificant,aschangingtheorderingchangesthese-
andmanticsall(e.g.furtherwhetherqualifiers).Theresynchronisationisonlyaappliessingleonlytobracketthelisttargetperortoobject,theandtargetthe
typeofthequalifyingobjectdetermineswhethertheycontainapplicablecall-in
Thebrackets,call-incall-outbracketsbracketsareoractivatedboth.inthebracketlistorder,butthecall-outbrack-
etsecutedinreversebeforeanybracketcall-inlistorderbrackets.ofThethecall-outtargetobjectbrackets(seeoftheFigureclient4.10).objectareex-

objectClientbracketcall-outcall-inbracketTobjectarget

listbracketQualifyingobjectQualifyingobjectlistbracket

Figure4.10:Bracketsequencingofcall-outandcall-inbrackets

Theinvocationofthetargetobjectisredirectedtothefirstbracket,whichcan
beappropriateeitheracall-outkeywordbracketcallorofthebodyisclientusedoratocall-inproceedbracketwithofthethenexttarget.qualifyingThe
objectinthelist.Iftherearenofurtherqualifyingobjects,thenthetargetobjectis
invoked.Allinvocationsaresimilartonestedmethodcalls.
methodThecallcodeoforthebodyqualifyingkeywordobject,maybutappearmayonlyanywherebeininvokedtheatmostappropriateoncebracketbefore
invokedreturning.codeThewillbracketeventuallyinvocationreturniscontrolanalogoustothetoaqualifiermethod.invocation,i.e.the
Bracketinvocationcanbeusedconditionally(continuingonlysometimeswith
theattacksnextfromqualifier)withinoranotatqualifierall,the(neverbodyreachingorcallthetargetstatementobject).canTbeoavoiddynamicallyreplay
calledonlyonceinabracketmethod.

4.1.7QualifierswiththeirOwnInstanceMethods
itNotcanonlyalsocanahaveitsqualifierownhaveitsinstanceownstate,methods,whichwhichiscanseparatebeusedfrome.g.thatoftoitsinitialise,target,
ofamodifyqualifierandremovewhichprotectsinformationmethodheldintheinvocationsstateofvariables.thetargetTheobjectfollowingthroughexamplean
ACL(seeFigure4.11)illustratesthis.
isTheallowedbracketornot,methodbasedofonthetheACLstatequalifierofthecontainsqualifier.theChangingcheckandwhetherqueryingtheaccessthe

130

Chapter4ModelforBracketingObjects

{ACLprotectedtypeinstance:openqvoidAccessRightsListsetRights(UniqueIduser,getRights(UniqueIdAccessRightsListuser);rights);
enqqualifiesbracketany:all(...)throwsAccessViolation;
}Figure4.11:TypedefinitionforaqualifierforACLprotection

ACLisAssociatingpossibleathroughqualifierthewhichsetRightsincludesandinstancegetRightsmethodswithmethodsatargetoftheobjectqualifierdoes.
notchangetheinterfaceofthetargetobject.Theinstancemethodsthataredefined
inobject.thequalifierDefiningamayqualifieronlybeforainvokedtargetifobjectthecallerdeliberatelyusesadoesreferencenottochangethethequalifiertype
ofthetargetobjectatall.

ConceptsLanguageProgrammingRelated4.1.8Thistechnique(togetherwithothernewtechniquesdevelopedinTimor)allows
matchedsoftwarewithcomponentsothertocomponentsbetoindependentlyproducesoftwaredevelopedsystems.whichcanThisbenewmixedprogram-and
mingparadigmisthereforeknownascomponentorientedprogramming(COP).
programmingComponent-oriented[157](AOP),programmingwhichwashasdevelopedsomesimilaritiesindependentlywithandaspect-orientedconcurrently
byconcernsKiczalesintoetal.reusableatXeroxpiecesPARC.ofcode,Theaimalongwaswithtorulesseparatethatsodefinecalledhowcross-cuttingsuchan
aspectmustbeintegratedintothecodetoworkproperly.
ifiersThecanmainbediffereaddedncetoiscodethatAOPwithoutrequireschangingtheit,white-boxtreatingobjectsapproach,asawhereasblackqual-box.
AOP(includinghasitsoperatingstrengthsinthesystems,designcf.and[268]),butimplementationitsbasephaseconceptsofcannotsoftwarebeprojectseasily
convertedtooperatingsystemconcepts.Thevarietyofpatterns(before-advice,
isafter-adviceappropriateandforpointcuts)individual,inwhichwell-definedtheaspectssoftwarearesystems.wovenintoThetherelativelytargetobjectstatic
bindingSomeisnotsimplifiedflexiblevariantsenoughofforAOPsoftwareareverysystemssimilarintoanOScontext.component-orientedpro-
gramming,suchastheAOPvariantimplementedinJBoss[83],basedontheEn-
ItisterprisebasedJavaonBeansintercepting[271]methodframeworkinvocationsincludedin(althoughJava2EnterprisepointcutscanEditionbedefined(J2EE).
AOPalso),.Inandisparticularapplicableitforsupportsblack-boxtheuseofobjectsandunmodifiedisalsoJavamoreobjects.dynamicOnthantheotherplain
handitcannotsupportthelargevarietyofwaystoweaveaspectsintoaprogram,
whicharedeemedessentialbytheAOPdevelopers.

BracketswithSecurityImproving4.2

131

utedTheapplicationsapproachinusedJava,inisOpsismore[78,79,closely80],arelatedtomiddlewarebracketing.forconstructingHoweveritsdistrib-main
aimisfine-grainedinformationhidingwithinasoftwaresystem.

BracketswithSecurityImproving4.2

Currentobject-orientedprogramminglanguagesarebasedonasimplifiedvariant
offorcapabilityinvokingitslists,sincemethods.havingBracketsacanreferencetosupplementanobjectthisisaarbitrarilyrequired,constructingpreconditiona
system.securityuser-implemented

4.2.1ExamplesofUsesofBracketing
Alargenumberofcasesofcodeduplicationinobject-orienteddesignshavebeen
lishedidentifiedastobeexamplessuitableintheforvariousimplementatiTimoroninpublications.qualifyingTimortypesisandstillhaveinthebeendesignpub-
phaseandnocompilerexistsyet.Therearenoexperienceswithlargesoftware
projects,butthewell-structuredcomponent-orientedprogrammingapproachcan
beQualifiersexpectedtohavesimplifybeendesigneddevelopmentforofmanysoftwarepurposes,systems.including:

debugging:yetimplementeddummyobjectsobjectstotospeedprotectupvaluabletestingofdataaorlargetosoftwarepartiallysystem.simulatenot

synchronisation:boundedbuffermutualmanagementexclusion,(see[147,reader/writer148]).exclusion,Hoare’smonitorand

transactions:transparentlymanagedshadowcopiesofobjects[154].

publications.QualifiersareTheynotcanlimitedconstitutetothesmallsubstantial,examplescomplexinthissoftwarethesisorinbuildingtheTblocksimor
(cfreuse,.[191]).whichcanTheirdecreaseseparatethedesignanddevelopmentcostimplementationofapplicationencouragessoftwareeffectivegreatly.code

BracketingviaSecurity4.2.2Someapplicationsofbracketmethodsareespeciallyrelevanttotheaimofachiev-
ingflexiblesecurity[144].Theseinclude:

revocationcapability•

listscontrolaccess•

controlaccessrule-based•

132

decoysmonitoring,access•

confining•informationofflow

Chapter4ModelforBracketingObjects

•restrictingallowableparameters,time-restricteddemoversions

Thesignificantadvantageofbracketingcomparedwithmostothertechniques
isthatitprovidesageneralpurposemechanismwhichenablesnormalusersin
bothmandatoryanddiscretionarysystemstoprogramarbitraryprotectionrules
andsecuritypolicies.Mandatoryanddiscretionaryaccesscontrolpoliciesmaybe
system.singleaonimplemented

4.2.3ConfiningFlowofInformationwithBrackets
Aclassofproblemsthatcangenerallybeimplementedwithcall-outbracketsonlyis
confinement,wheretheflowofinformationmustbeconfinedtotrustedmethods.
callsCallstomustanybeothercheckedmethodforneedsunallowedtobedestinationprevented,andmethodsthusorobjects.potentiallyalloutgoing
OtherusescouldbethepreventionofdamagebyaTrojanHorseinthecode
ofintegrityoneof(e.g.thefileobjects.accessesbyUnintendedobjectscallswhichtoobjectsshouldthatonlycouldworkwithviolatetheirtheinternalsystem
data)caneasilybedetectedwithoutotherwiseinterferingwiththeobjects.
Implementingsomeadvancedaccesscontrolschemes(includingschemesthat
e.g.controlthetheBell-LaPflowofadulamodelinformation)canisbepossibleimplementedwithoutinTrevertingimorto[151].call-outHereonlybrackets,an
excerptisusedtoillustratetheimplementationidea.
Allincomingcallsmustbecheckedforpotentialinformationtransfertosubjects
ofandefinitionininappropriateFigure4.12clearanceprovideslevelaandmakerinvalid(similarcallstohaveatobeconstructorrejected.inJava)Thethattype
thatdefinesmanagesthethenecessarysubjectspropertiesandofrecordsthetheirobject,clearanceincludingaaccordingreferencetothetothemodel.object

{BellLaPadulatypemaker:objectClassification;methodCount,init(intint[]boolean[]projectList;restrictedOps,BellLaPadulaSubjects*restrictedEnqs;subjectsFile);
instance:objectClassification();intenqenqqualifiesbracketany:all(...)throwsConfinementViolation;
}

Figure4.12:TypedeclarationofaBell-LaPadulaqualifyingtype

BracketswithSecurityImproving4.2

133

Theinformationpassedtothemakerisstoredintheprivatedataofthequali-
fyingobject,andthereisasamplemethodtoquerytheclassificationofanobject.
Thebracketcontainsthekeyfunctionality,namelytheaccesscheck,basedonthe
identityofthecaller.Toimplementthischeck,thebracketmustbeabletofindout
object.thecalleduserwhich

SPEEDOSPhilosophySecurityBasic4.2.4InpossessionSPEEDOSof,asecuritycapabilityisbasedgivingonaaccesscombinationtotheofmethodcapabilitiesoftheandtargetbrackets.objectisThea
necessaryprecondition.ThisissimilartothemodulecapabilitiesintheMONADS
system.Thebracketmechanismallowsuserstoimplementanysecuritypolicythey
deemsystemavoidsappropriate.theUsingproblemswithcapabilitiesasACL-basedtheapproaches,implementatione.g.basistheforbrowsingtheprotectionproblem
2.7.2.1.sectioninmentionedifAccessnecessary.controlThelistscombinationandotherofprotectionearly-boundchecksaccesscanberightsdecisionsimplementedbyrepresentedqualifiers,by
combinecapabilitiestheandadvantageslate-bound,ofbotharbitrarilycapabilitylistsprogrammableandaccesscheckscontrolinlists.bracketmethods
otherQualifierssecurity-relatedarenotlimitedoperationstoaccesssuchaschecks,accessbutmaymonitoring.alsoInbemanyusedtooperatingimplementsys-
temscasesthisareislesseitherflexibleafixedthanparttheofthebracketingprotectionconcept,systemwhichorisisnotfreelyenforceable.programmableBoth
andsupportsdynamicchangestothelistofqualifiers.

Security-BasedCompiler4.2.5ationProvidingofqualifiersmechanisms,alsoatbecausethetheoperatingprogrammingsystemlevellanguagepotentiallyitselfmaycreatesaprovideduplic-the
sametecture.functionalityQualifiers.attheHoweverOSlevelthetwoareavailableapproachesforanyachieveamodule,differentindependentsecurityofarchi-the
Relyingprogrammingsolelyonlanguageusedlanguage-basedtoimplementmechanismsit.toimplementprotectionrequires
ainallcarefullypartsofcheckedthelanguageapplication,design,preventingaverifiedunwantedcompilerandaccess.anFinallyappropriateitmustdesignbe
guaranteedthatno“unsafe”programminglanguagemaybeusedintheentire
basedsystem.securityWhilearethesenotconditionssatisfying.mayallbefulfilled,theexperienceswithcompiler-
Programminglanguagesaredesignedtobeprogrammer-friendlytoolstopro-
ducecompilersoftwareinseparablysystems.addsPuttingcomplexitythetoburdentheoflanguageensuringandprotectiondecreasesthesolelyonprogram-the
merefficiency.Somelanguage/operatingsystemcombinations(e.g.Oberon[303])

134

Chapter4ModelforBracketingObjects

havetriedtoavoidthecostofanOSthatprovidesitsownprotectionsystem,but
asaconsequencealsofailedatprovidingtrueprotection.
EvenInifSPEEDOSthetheapplicationuserdecidesmoduleiswhetherimplementedhewantsintoauseprogrammingqualifiersatthelanguageOSlevel.that
providesbrackets,theusermaystilldecidetousequalifiersattheOSlevel,because
theysecuritycanisbeconsideredappliedtowithoutbeinsufficientchangingintheSPEEDOSapplication.module.Compiler-based

4.3ImplementingBracketsinOperatingSystems

Sofarbracketsweredescribedasaprogramminglanguageconceptthathelps
hasstructuringnotbeensoftwareattemptedinthesofarlightinofthereusabilityliterature.orUsingknownbracketsoperatingasanOSsystems.conceptWe
nowconsiderhowthebenefitsofbracketingmightbeachievedattheOSlevel,i.e.
isRiteusablefeasibletocodeissupportalsousefulbracketingintheasanOSOScontext,concept?butthemainopportunityforim-
AprovementsqualifieratisthetheOSflexibilitylevel,isalsoespeciallyathefirst-classabilityOStoobjectreflect(e.g.flexibleamodule),securitywhichpolices.is
ofindependenttarget(s).theBracketsasanOSmechanismforcomplementingthenormalprotectionmechan-
ismsbreachesprovideofacontrolsecurityoverpolicyaccessarerightsdetected.atrun-time,Actuallymanywhichisbasicespeciallyprotectionusefulmechan-when
ismspossibleprovideornotnofine-grainedopportunitytoenoughdetecttobreaches,conclusivelyasdeterminemonitoringiswhichoftenusereitheractuallynot
causedtheviolation.Trustworthyauthenticationinformationmustbeavailable
duringsponsiblethefortheexecutioncurrentofaactivitybracketandmethod,thei.e.identitytheoftheidentityclientoftheandusertargetwhichmodules.isre-
alsoBracketshavetointhematchOSthecontextgranularityarenotoflimitedtheOStosecuritybracketaspects.mechanism.HoweverTheotheroperatinguses
systemBracketsatknowsthisonlylevelaboutincurthelargeoverheadobjectsof(e.g.anyothermodulesOSinobject.theMONADSsystem).
mingSmalllanguagebracketslevelcan(ifoftenthebeprogrammingimplementedlanguagemuchmoreprovidesefficientlybracketing)atthewithinprogram-an
objectknowntotheOS.Thevarioussynchronisationmechanismsareanexample.
Theamountofcodeinthebracketisfairlysmallanddoesnotwarranttheoverhead
ofanadditionalOSobjectinvocation.Thesituationisdifferentformorecomplex
maysynchronisationguaranteeatomic,schemes,suchconsistent,asisolatedtransactions.andTdurableransactionsupdatesatthetoOStheobjectlarge-scalelevel
OSAlsoobjects.bracketsThedosystemnothavedesignertoreplacedecidesthewhichconventionalimplementationOSprotectionstrategyismechanismsused.
accessentirely.controlTheyareconditions,usefulinsuchascombinationarbitrarywithaccesscapabilityrules,listswhichorACLs,cannottobeimplementdefined
mechanisms.protectionconventionalthethrough

4.3ImplementingBracketsinOperatingSystems

135

Prerequisites4.3.1toInbeanOSqualifiedthelaterrequirementisnotofrealisticallyhavingtheachievablesource.codeofBracketingallobjectsworksinthatamayblack-boxneed
context,byinterceptingmethodinvocations.AssuminganOSdesignthatknows
aboutobjectsobjectswithoutwithhavingsemanticaccesstointerfaces,theiritsourceispossiblecode.toThisismodifyespeciallythebehaviourusefulforof
definingthesecuritypolicywithoutchangingthecodeoftheobjects,butmayalso
beTheusedforbracketarbitraryconceptothercanonlybehavioureffectivelymodifications.improveOSflexibilityifqualifierscan
beandaredynamicallybetterusedaddedattheandremovedprogrammingatrun-time.languageStaticlevel.bracketsBracketsmakecanlittleremedysensethe
disadvantagesofcapabilities,byaddingfurther,late-boundaccessconditionstothe
objects.targetofinvocationBracketsareanidealmatchtoanin-processimplementationoftheOSandap-
plications,basedoninformation-hidingmodules.Thisenvironmentisverysim-
ilarfollowingtotheconceptsdescriptionoftheassumesancomponent-oriin-processenteddesign,programmingbutcanbelanguagealsoTappliedimor.withThe
appropriatemodificationstoout-of-processdesigns,e.g.basedonmessagepassing.
Anunavoidablepreconditionforbracketingisthatthereisanotionofasemantic
interface,sothattheOScanselecttheapplicablebracketsandorganisethenested
butinvocationthisisinofanybracketcasemanethods.essentialThiskernelrequiresfunctionalitycontroloverforanthemethodin-processsystem.invocations,
rules,SelectingbecausethemostapplicableoperatingbracketssystemsforOSonlyobjectshaveaprobablyweaklyneedsdefinedslightlytypedifferentsystem.
Basingtheselectionexclusivelyonthemethodsignatureswouldforceanotherwise
unneeded,distincttypesystemintothekernel.Amoreelaboratetypesystemcan
bethatallowsimplementedtheattheinvocationuseroflevel,arbitrarye.g.inthemethodscontextofaofamodule(cfcommand-line.thedescriptioninterpreterof
thecommand-lineinterpreterfortheMONADSsysteminsection3.3.8).

4.3.2ProtectionofParameterListsandReturnValues
InTattention,imortheasinamanagementprogrammingofparameterlanguagelistsitisandseldomreturnnecessaryvalueshastobeencontrolgiventheflowlittle
ofinformation.Itwassufficienttoprovideamechanismforpassingonunknown
values.returnandlistsparameterInanOScontextaccesstotheparameterlistofanobjectinvocationismuch
moresecuritysensitive,asparameterlistsmaycontainsecurity-sensitiveinform-
ationpasswords.suchasThesecapabilities,canbeobjectmisusedreferencespotentiallyorbyanyauthenticationbracketthatcaninformationaccesssuchpara-as
values.returnand/orlistsmeterAccesstoparameterinformationmustbethereforetightlycontrolled.Most
bracketsneednoaccesstoparameterlistinformation,andthisshouldbeenforce-

136

Chapter4ModelforBracketingObjects

ablebytheOSbynotgivingthebracketaccess.Thereforethebracketlistmust
containinformationabouttheparameterinformationaccessrights.Thebody
notprimitivehavemustaccesstoforwardthem.theTheparameterbracketslistandhavingreturnaccessvaluestoevenparameterifabracketinformationdoes
mustbeisolatedagainsteachother,i.e.themodificationstotheparameterlistby
antheinnerreceivedbracketparametermustnotlistbeandvisiblerestoringtoanitouterwhenthebracket.nextThisinnerrequiresbracketsavingreturns.of
Informationleaksthroughmanipulatedparameterlistsmustbeprevented,e.g.by
markingparameterlistsasread-onlydataoncebodyhasbeeninvoked.
tionisHandlingstrictlyoffromreturnthevaluestargetisobjectslightly(ifiteasierwereineverthisrespect,reached)astothetheflowclient,ofinforma-because
itisanerrortoinvokethebodyprimitivemorethanonceinabracketmethod.
Thisrestrictionisenforcedintheimplementationofbody.
Thememorymanagementrequiredtoachievethisstructureissomewhatcom-
plicated,asthedeallocationofparameterlistsneedstobedeferredtothecreator
oftheaparameterparameterlistlist.copyingTheallocationoperationisdoesnotavoidedfollowforthebracketsstackthatdisciplinehavenodirectlyaccesstoif
information.parametertheRagement,eturnasvaluesonlyaretheoftentargetlimitedobjecttoknowssimplethetypessizeinoforderthetosimplifyinformationitmemoryneedsman-to
return.Asthisissimilartothememorymanagementforparameterlistpassing,
thelingofrestrictionparametertolistssimpletypessymmetricaloffixedtothesizecanreturnbevaluesdropped.andThiseliminatesmakesthepassinghand-of
referencesto“returnvalueobjects”constructedsolelyforthispurpose.

ListsBracketManaging4.3.3IfsiontobracketsmanageareusedbracketsasalistssecuritybecomesmechanismacrucialinthepointOSincontextsystemthensecuritythe.permis-Access
tobracketlistsmustbecarefullycontrolledtoachieveatrustworthymanagement
systemaccordingtoacertainsecuritypolicy.
Thisprerequisitecouldofbeperceivedtrustworthinessasaofweaknessaccessofrightsusingbracketsmanagementtoiscontrolactuallyaccess,abutpropertythe
ofallimportance,accessandcontrolisusuallysystems.veryThetightlypermissioncontrolled.toThechangepossibilityaccesstorightsprotectisofbracketpivotal
listsagementthroughpolicy,bracketsoftenactually“hard-wired”addsintoflexibilitytheOS,asitkernel.doesnotenforceasingleman-
rightThetoabilityextendtoaccessmodifyarightsbracket(uptolisttheaccesscontainingrightsaccessdefinedinrestrictionstheACLisorsimilarcapabilitytothe
list).Evenremovingbracketsthatdonotcheckaccessconditionscanviolatethe
securitypolicy,e.g.byevadingaccessmonitoring.
everyNotonlybracketcanremovingeasilybrackets,causedenialbutofalsoserviceaddingtoallbracketsclients.isBracketssecurity-sensitive,withaccessas

4.3ImplementingBracketsinOperatingSystems

137

toparameterinformationmightcontainTrojanHorsefunctionality,asparameter
information.valuablecontainoftenlistsbracketTheselistofcomplicationsanyobject.canInallabesolveddiscretionarybybeiaccessngcarefulcontrolwithsystemreferencesoftenonlytothethe
owneroftheobjectitselfhasaccesstothebracketlistandnooneelse.Inaman-
datoryaccesscontrolsystem,bracketlistsmaybemanagedthroughasetofobjects
whichenforceacertainsecuritypolicy.
risk.SimilarlyTheTtoimortheTimorapproachcontext,ofevenreturningreadonlyaccesstoidentifiersabracketofthelistmayqualifyingbeasecurityobjects
couldalsobeusedtoguaranteetheintegrityofqualifiers,iftheOSprovidesno
meansoftransformingidentifiersintousableobjectreferences.
Inasystemwithsemanticaccessrightsthiscanbeadequatelycontrolledby
thanprovidingtheusualsuitableinsertormanagementremovefunctionsfunctionsthatforprovidestandardamorelists.fine-grainedcontrol

ConceptsSystemOperatingSimilar4.3.4Flask(thesecurityarchitecturebuiltonamodifiedFlukemicrokernel)seemsto
haveverysimilaraims,butusesatotallydifferentimplementationapproachto
sinceachievetheyaareflexiblenotprotectilimitedontosystem.arbitraryaccessBracketshavechecks.aFlaskmuchwiderachievesaapplicationsimilarflexib-range,
ilityforexpressingprotectionconditions,butitdoesnotsupportaddingfunction-
alitytoobjects,e.g.accessmonitoring.
temptedExokernelsto(cfincrease.thetheXNfilesystemsystemflexibilityinXok,byoutlineddownloadinginsectioncodeinto3.10.3)thehavekernel.at-
Thisrequirescodeverificationtopreventmaliciouscodefrombeingintroduced
ofintotrusteddownloadscode.islowThis.isThisacostlylimitstheoperation,scalabilityandisofonlyexokernels,worththeprovidingeffortifathehigherrate
flexibilityonlyforfairlystaticlibraryOSdesigns.
inclusionThustheinarigid,trulysimpleflexibleOS.conceptBracketsbehindfavourbracketsOSisdesignsafarbasingsuperioronthecandidatein-processfor
modelandonobject-orientedprinciples,butcouldbeadaptedeventosystems
beimplementingremovedisthetheneedout-offora-processsensible,model.Theinformation-hidingonlyprerequisiteinterface.thatcannoteasily
Inamicrokernelimplementation(i.e.out-of-process),themessagestoaserver
haverespondstobetothetransparentlyredirectionofredirectedmethodtothecallsinappropriatethecontextof“qualifyinganin-processserver”.Thissystem.cor-
The“lax”handlingofnestingcommoninremoteprocedurecallimplementations
the(whennoinvocationreturnofthevaluespostludearetobecodeofpassedabracket.backtoThisthecanclient)befixedcausesbyproblemssendingaddi-with
tionalemptymessages,whichprovidethesynchronisationforcontinuingwiththe
inanpostlude.in-processThusbracketssystem.inThisanout-ofillustrates-processthesystemstructuringareactuallyproblemslessthatareefficientinherentthan

138

Chapter4ModelforBracketingObjects

withmessageasystempassingdesignisbasedunnecessarilyonmessagecomplicatedpassing.andImplementingexpensive,methodespeciallycallsifausinghigh
levelofconcurrentactivityisdesired.

Summary4.4

Themaintopicofthischapterwastheuseofbracketmethodsinsoftwaresystems,
whichcangreatlyincreasetheflexibility,extensibilityandsecurityofthedesign.
Bracketsarepartofthecomponent-orientedprogrammingparadigmdeveloped
withTimor,whichintendstosupportamuchmorefine-grainedcomponentdevel-
theopmentprogrammingstylethaneffortearlierrequiredattemptsto(cf.create[191,anew273].Rapplicationeusabletothecomponentsminimumreduceand
asaSinceconsequencebracketsalsoweredecreaseinventedtheasanamountextensionoftestingtorequired.object-orientedprogramming
languages,itisnotsurprisingthattheyalsofiteasilyintooperatingsystemsbased
onfinedintheinformation-hidingnextchapters,modulesleadingandtoathenewin-processwaytomodel.structureThisoperatingwillbesystems.furtherre-
HavingreusableOScomponentsisveryattractive,astheycanbedeployed
Beingquickly,ablewhichtouseisoffespecially-the-shelfvaluablecomponentsintosituationsmonitorwhichaccessesrequireandspeedyforquicklyreaction.re-
configurableaccesscontrolcheckshelpsgreatly,giventhatnosecuritysystemis
Tperfect.odaysoftwareAdditionallysystemsthewideplayanapplicabilityimportantdecreasesroleintheallcostwalksofofsuchlife.Thecomponents.ever-
changingenvironmentforsuchsystems(inthesenseofrequiredconformanceto
thetriedtohumantackle.society)BracketplacesmethodschallengeswillwhichplayasokeyfarroleveryinfewSPEEDOSoperating,systemsprovidinghavethe
basisforaflexible,freelyprogrammableprotectionandsecuritysystem,andalso
forotherOSextensionssuchastransactionmanagers.
Theabilityofbracketmethodstoserveastheirownflexibleprotectionmech-
foranismfreelywillavoidprogrammabletheneedforpermissionspecialchecks.meThischanismskeepsforthemanagingOSdesignthesimplemetarightsand
bracketsminimisesarethethenumberbasistoofimplementprotectionasuperiormechanisms.securityComparedsystem.tootherOSdesigns,

5Chapter

CompositeforModelModules

139

Ingeneralsectionstructural3.12.2theconceptsdecisionwassupportedmadebytothebaseMONADStheSPEEDOSandGrasshopperarchitectureonsystems.the
Themainreasonforthisdecisionwasthelattersystems’superiorsoftwareengin-
eeringdesigns.andHoweverprotection,thissupportdecisionforwasmadeapplicationinfullmodules,awarenesscomparedthatwithneithermicrokernelMONADS
norGrasshopperwasdesignedwiththeexplicitaimofreducingtheirkernelstoa
minimalcorenecessarytosupporttheseideas.
TheneedforaminimalkernelinSPEEDOS,incontrast,hasbecomemuchmore
importantintheviewofthedecision,describedindetailinchapter4,tosupport
requiredqualifyingtotypessupportwithbracketbracketmethodsmethodsforineachSPEEDOSinter-modulesystems.callSimplywouldtoaddtheenormouslycode
withcomplicatebothaMONADSmonolithicandGrasshopperkernel—even.whenthisiswell-structured,asisthecase
ProvidingaminimalkernelwhichsupportsanarchitecturesimilartoMONADS
isantechniqueasyetwhichunsolvedallowsthisproblem.aimThetobepurposerealisedofinthisaflexiblechapterisandtopresentextensibleawaynew.
Thefunctionalitytechniquewithaddressesuser-levelthemodules.generalproblemofimplementingoperatingsystem
theseInaimssectionare5.1theanalysedaimsofandthen,minimalonthekernelsbasisareoftheconsidereddescriptioninmoreofdetail.microkernelFirst
systemsachievedinalreadysuchpresentedsystems.inTherechapterare3,itbasicallyisshowntwothatproblems.theseTheaimsfirstareisonlyrelatedpoorlyto
tothethisout-ofproblem-processisamodelmajorthemeadoptedininchaptermicrokernel6(whichsystems.discussesThetheSPEEDOSSPEEDOSresponsekernel
indetail).Thesecondproblem,whichisdirectlytackledinthischapter,isthelack
offlexibilitywhicharisesfromthemicrokernelpracticethatkernelfunctionalityis
notalwaystailoreddelegatedtothetodifferentmoduleswhichrequirementsprovideofindividualcentralisedpoliciesapplications.thataretherefore
ThisAsolutionconceptisallowspresentedinapplicationtheformmodulesofanewtobeOSdefinedstructuringascompositeconceptinmodulessection.5.2.The
listsbasictheideaisindividualpresentedco-minodulestermsofofanadataapplicationstructuremodule(theandCo-moduleisTmanagedable)bywhichthe
specialco-moduleCo-moduleManager.Eachco-moduleisitselfaninformation-

140

Chapter5ModelforCompositeModules

forhidingthemodule,appropriatewhichcanco-module.beTheindependentlyco-moduleinvokedconceptonlycanbybeholderscombinedofawithcapabilitythe
bracketingconceptdescribedinthepreviouschapter.
tionalityThechaptercanbeisdelegatedconcludedtobyreturning“user”-leveltothemodules.generalthemeDependingofonhowthekernelfunction-func-
alityinquestion,thisdelegationcanbetocentral(typicallyresourceallocating)
modules—asoccursinmicrokerneldelegation—ortoco-modulesofapplications,
whichnatureofarethenotfunctionalityenvisagedintobemicrokernels.delegated.TheThestyleresultisisaselectedkernel,whichdependingonthe
a)providesadefinedinterfacetoapplicationmodules,and
b)itselfreliesontheavailabilityofuser-levelmodulestocarryoutitstasks.
TheimplicationsforthedesignandstructureoftheSPEEDOSkernelarethendis-
6.chapterincussed

5.1AimsbehindMinimalKernels

TheminimisingsizeofantheOSkernelkernelsizeiscorrelatesthedesirewithtoitsreducecomplexity.complexityThe.primaryHoweveraimtherebehindare
thatotherfactorsattemptedthattominimiseinfluencethethekernelfeasibilitysizeof(cfa.kernelchapter3)design.actuallySofarallincreaseddesignsthe
structuringandprotectionproblemsinsteadofeliminatingthem.
Anothermotivationtominimisethefunctionalityofthekernelistoachievea
flexibleandextensibleOSdesign.Operatingsystemswithdifferentcharacteristics
maybeimplementedusingasinglekernel.Thiscodereuseaspecthoweveris
oftenhamperedbythefactthatmostsuchkernels(e.g.Mach)implicitlyfavoura
e.g.particulartheOSMONADSdesign.kernelItwouldbasedbeonbothMach,complicatedbecauseofandtheinefficientmismatchtobetweenimplementthe
models.memoryandprocess

5.1.1RelationshipbetweenSizeandComplexity
Eventheimplementationofasimplekernelisalreadyarelativelycomplicatedtask,
becauseofthecomplexityofcurrentprocessorarchitectures.Theentirekerneltyp-
icallyexecutesinaprivilegedmode,whichgivesunrestrictedaccesstoallresources
inthecomputersystem.Largekernelshaveahigherriskoferrorsthreatening
thesecurityofthekernelandtheentiresystem.Asaconsequence,newerkernel
designsattempttoreducethecomplexitycausedbytheirowndesign.Smallcode
sizeandawell-structuredimplementationarealsoprerequisitesfortheverifica-
tionofthekernelfunctionality,irrespectivewhetherthisisperformedbymanual
inspectionorthroughautomatedformalproofs.

5.1AimsbehindMinimalKernels

141

ativelyAnotherstaticaspectsoftwareisthatentities.kernelsItisarenot(infeasiblecomparisontomodifywithanOSapplicationkernelinmodules)asimilarrel-
waytoapplicationsoftware,becausereplacingthekernelisusuallynotpossible
whilereducingthetheOSandkernelapplicationsfunctionalityare,namelyrunning.theThisaimtoillustratesincreaseanothertheflexibilitymotivationofthefor
timekernel.thatwouldDelegatingbemostrequiredforfunctionalityakerneltomodificationuser-leveltocodebecomecaneliminateeffective,theassumingdown-
thatuser-leveltheuser-levelprogramsiscodecangenerallybemorereplacedversatileatrun-time.thanforThethekernel.linkingmechanismfor
codeMinimisingpromisetothemakekerneltheandbenefitsdelegatingofcurrentoperatingsoftwaresystemengineeringfunctionalitytotechniquesuser-levelavail-
ableavailableinthewithOScontext.information-hidingEspeciallythemodulesflexibilityareandattractive.extensibilityHowevertheimprovementsattempts
atcauseminimisingtheirthestructuralcodeofchangesdokernels—especiallynotaddressthediversemicrokernels—arerequirementsnotofsatisfying,currentbe-
applicationsoftware.Thefundamentalproblemisthatthereisnocleardistinction
kernel,betweenandthetheessenceaccident,ofi.e.kernelthepoliciesfunctionality,requiredi.e.thebyindividualmechanismsapplications.providedbythe

5.1.2DistinctionbetweenMechanismandPolicy
TheproblemwasalreadyidentifiedintheHYDRAproject[306,307,172].The
followingquotefrom[306]clearlyformulatestheproblemswithconventionalsys-
improvements:potentialtheandtems“2.Separationofmechanismandpolicy.Amongthemajorcausesofour
inabilitytoexperimentwith,andadapt,existingoperatingsystemsis
theirfailuretoproperlyseparatemechanismsfrompolicies.[...]Such
separationcontributestotheflexibilityofthesystem,foritleavesthe
complexdecisionsinthehandsofthepersonwhoshouldmakethem—
designersystemhigher-levelthe.”wheneverManyOStheredesignswastheafterdangerHYDRAoftookaovernoticeablethisefficiencyprinciple,butlossordepartedwhenitsfromuseit
causedkernelorOSstructuringproblems(sometimestheprocessorarchitecture
makesthedelegationofcertainpartsofanOSkerneldifficult).Thereforeinmost
operatingsystemstheseparationofpolicyandmechanismissacrificedwhenever
suchdifficultiesareencountered,resultinginaninconsistentdesign.
Inmicrokernels,theprincipleisinterpretedinaverylimitedsense,namelythat
allservices—exceptthemessage-passingimplementation—aredelegatedtouser-
levelservers.Thisdecreasesthesizeofthekernel,butdoesnotprovideasubstan-
tialmodel.flexibilityAdditionallyimprovementtheoverimplementationmonolithicofamessagekernelsbasedpassingonfacilitytheinout-ofthe-processkernel
isitselfaviolationoftheprinciple.Mostmicrokernelsimplementthescheduler

142

Chapter5ModelforCompositeModules

inthekernel,becauseinasystemfollowingtheout-of-processmodeltheability
toswitchtoanotherprocessiscrucial.Asaconsequencemechanismsandpolicies
arenotclearlyseparated,whichaffectsthestructureoftheuser-levelservers.The
flexibility,extensibilityandsecuritysuffersfromthisfundamentaldesignincon-
sistence.Mixingpoliciesandmechanismsinakernelshouldbeavoided,because
itadverselyaffectstheflexibilityoftheoverallsoftwaresystem,consistingofthe
kernel,theoperatingsystemandtheapplications.
Reducingthekernelsizeisnotanendinitself.Itisalsopossiblethatthenumber
ofmechanismsinakernelisreducedtoomuch(e.g.intheexokernelapproachor
inmicrokernelswhichfitinafewKbytesofmemory,suchasL4).Thisleadsto
functionalityandflexibilitydecreases.Thusthisextremealsohastobeavoided.

5.1.3PrerequisitesforaPolicy-NeutralKernel
Kernelfunctionalityreductionusuallyrequiresincreaseduser-levelfunctionality.
Theassumeuser-levelmoremodulesresponsibility(bothinspeordercialtoOSretainmodulestheandpreviousapplicationfunctionalitymodules).Dependinghaveto
ontheproblemathandthefunctionalityisbetterdelegatedtoacentralmoduleor
associatedwithineachapplicationmodule,asweshallnowshow.
suitableTheforapproachtofunctionalityassociateaspectspolicythatdecisionsrelatetoawithparticularindividualapplication.applicationsisGenerallyonly
anapplicationapplicationisisoftencapablenotofinterestedmanaginginitsmanagingownglobalresources,resourcee.g.itsownallocationmemoryfairly..An
InthefollowingsectionsanewapproachfordelegationofOSfunctionalitywill
beitatesdescribed,flexibilitywhichandallowsextensibility,asdecentralisationitallowsofspeciallyfunctionalitytailored.Suchaimplementationsstructurefacil-to
beusedwheretheapplicationrequiresthis.

5.2NewOperatingSystemStructuringApproach

Separationofmechanismandpolicyisanaimclaimedbymanyexistingoperating
systems.relocationofHowevercodefromgenerallythekernelitistointerpretedcentralisedinauser-levellimitedwaymodules.,focusingThisonseverelythe
arestrictssinglethepolicyforflexibilityallandsituationsextensibilityduetotheofthecentralresultingimplementation.system,asitfavoursusing
theInthisdelegationsectiontoathenewmoduleapplicationstructuringmoduleortomechanismcentralismodules,proposed,dependingwhichonsupportsthe
OSatedtoanfunctionalityapplicationinquestion.moduleAnisexamplemanagementforofitsfunctionalityownpagethattable.shouldbeThisdeleg-page
tablewhichitmanagementcontainsinformation,functionalityi.e.isitinresemblesprincipleanindependentindependentofthemodule.moduleHoweverabout
itisdesirabletoassociatethepagetablemanagementmodulewiththeapplica-
tionmoduleforwhichitisresponsible.Thekernelshouldonlyimplementasetof

5.2NewOperatingSystemStructuringApproach

143

virtualprefetchmemorystrategy)shouldmanagementbeimplementedmechanismsbyandthethepagepolicytable(suchasmanagementanappropriatemodule.
Suchapagetablemodulecontainsthemappingbetweenvirtualaddresseswithin
amoduleimplementation.andblockThispagenumberstableonisdisc,differentasrequiredfromtheforaper-processorpersistentpagevirtualtablememorythat
mapsThesebetweenstructurespagecannotnumbersbeandrepresentedmainmemorydirectlypagebyframes.modulesassupportedinthe
MONADSandGrasshoppersystems.Theunderlyinginformation-hidingmodule
doesconceptnotproposedattempttobyPsolvearnasthe[215]specificisageneralproblemsofsoftwareOSstructuring.structuringThisapproachindicatesand
thatthemodulessupportedbyMONADSandGrasshopperneedtobeenhanced,
modules.compositeformingtheInOSthisfunctionalitydescriptionitisaspectsassumedofcompositethatthekernelmodulestoitselfiscarrynotoutaitsmodule.tasks,Itbutusesis
notsupportforimplementedmodules.intheTheformmostofaimportantcompositekernelmodule.operationTheinkernelthiscontextimplementsisthethe
thebasisinter-moduleforcall,protection.whichallowsmethodsofothermodulestobeinvoked,providing

StructureCo-Module5.2.1Inresentthefirstcompositeplace,modulesmodulesthat(asmustsupportedbeinseparatelyMONADS)protected.wereThenotOSdesignedfunctionalitytorep-
delegatedrequirementstothanco-modulestheofanapplicationapplicationmodulemoduleitself.typicallyHoweverhasthedifferingMONADSprotectionmodule
structure(seeFigure5.1)issuitabletorepresentindividualco-modules.
Module

privatedatamoduleof

Implementationcode

Figure5.1:Conceptualstructureofaninformation-hidingmodule

onlySuchwaytoaccessinformation-hidingtheencapsulatedmodulespreventprivatedirectdataaciscesstothroughtheirusingprivatethedata.interfaceThe
methods.Torepresentthisstructure,thereisareferencetothecodeimplementing
theinterfacestoredwithintheprivatedata.
Itisnecessarytoextendthismodulestructureinordertosupportcomposite
co-modules.severalofconsistingmodules,

144

Chapter5ModelforCompositeModules

StructureModuleComposite5.2.2Aapplicationcompositemodule.moduleisThetheapplicationaggregationofmoduleallitselfco-modulesisalsobelongingconsideredtoaaco-module.particular
Thewithinnotionacomposite“module”ismodule.fromOfnowcourseonusedsuchtoreferapplicationtotheco-modulesapplicationimplytheco-moduleex-
istenceofco-modulesimplementingtheOS-relatedfunctionality.
plication,Co-modulesnotasareaintendedstructuringtomechanismrepresentOforSthefunctionalityactualapplicationassociatedwithfunctionalityan.ap-
Therepresentationofacompositemodulerequiresamoreflexiblerepresenta-
tionthanthemodulesavailableinMONADSandGrasshopper,becauseithasto
accommodateseveralco-modules.Eachco-moduleneedstohaveareferenceto
itsreferencesimplementationcomprisecodetheandaCo-modulereferenceTable,toitswhichprivatedefinesdatathe(seeassociationFigure5.2).betweenThe
privatedataandimplementationcodeforeachco-module.

ModuleCompositeableTCo-ModuleApplicationPcodeageTablecode
dataprivateDebugapplicationofcodedataprivatetablepageof

Figure5.2:Structureofacompositemoduleconsistingofseveralco-modules

atedfromConceptuallythatofthetheprivateotherdataofco-modules.eachco-moduleHoweveristheseparatelyuseofprotectedreferencesandtoisol-the
privatedataofeachco-modulecreatestheopportunitytosharetheprivatedata
betweenco-modules.Thisisonlyusefulforcertainspecial-purposeco-modules
whichviolatetheinformation-hidingprincipleandisdescribedinsection5.2.5.
Thestructionlongofeachlifetimeofcompositecompositemodulemodulesfromitsintheco-modules,OScontextandalsofavourscreatesdynamictheneedcon-
toallowstreatmixingindividualandmatchingapplicationofmoduleimplementationsinstancesfordifferentlydifferent.Theco-modules.Co-moduleTable
Usingaspecialimplementationforaco-module(e.g.apagetableco-modulethat
implementsapagingstrategytailoredtotherequirementsofacompositemodule)
toimprovetheperformancecharacteristicsoftheapplicationco-moduleisanobvi-
oneous,modularimplementationandofflexibleaco-moduleoptimisationwithstrategyanother.Itatisinrun-time,principleprovidedpossibletothatthisreplaceis
synchronised.carefully

5.2NewOperatingSystemStructuringApproach

145

ManagementCo-Module5.2.3byTheaspecialCo-moduleTco-module,ableisthenotaCo-modulefreestandingManagerdata(seestructure,Figurebut5.3).isTheitselfCo-modulemanaged
ManagerisresponsibleforallupdatestotheCo-moduleTable.
ModuleCompositeCo-ModuleTablecodeCo-ModuleManager
PageTablecodeApplication
codedataprivateDebugapplicationofcodedataprivatetablepageof

Figure5.3:CompositemodulecontentincludingCo-moduleManager

Infactwhenanewcompositemoduleiscreated,itinitiallycontainsonlyaCo-
moduleTablewithareferencetotheCo-moduleManagercode.Withthisstarting
point,itispossibletoupdatetheCo-moduleTableappropriately,bysettingup
entriesfortheapplicationandallotherrequiredco-modules.TheCo-moduleMan-
agerplaysakeyroleinthesecurityofthesystem,becauseitshapesthecontents
ofacompositemodule.TheCo-moduleManagerisaninformation-hidingmod-
ulelikeallotherco-modules,thustheavailablemodificationsaresubjecttothe
availableinterfacemethodsandthepossessionofanappropriatecapability.
ThecreationofanewcompositemoduleisultimatelythetaskofacentralOS
module,whichperformsthenecessaryresourceallocation.Thedetailsofthismod-
ulearedescribedinchapter6.

Co-ModulesofInvocation5.2.4Eachco-moduleisanindependentmoduleintheMONADSsenseandisseparately
Figureprotected.5.4)Inhastoorderbetoinvokepresented.amethodofaco-module,asuitablecapability(see

CompositeModuleIdentifierCo-ModuleNumberAccessRights

Figure5.4:Possiblecontentofacapabilitytoaco-module

146

Chapter5ModelforCompositeModules

Co-modulesbelongingtoasinglecompositemoduleshareacommoncomposite
fieldmoduleintheidentifiercapability,and.theThedistinctionco-modulebetweennumbersareco-modulesassumedisthroughtobeanuniqueadditionalonly
withinthecontextofacompositemoduleidentifier.

unctionalityFCo-ModuleWhite-Box5.2.5Theblack-boxmodelwhichisthebasisfortheinformation-hidingprincipleisuse-
fulfortheconstructionoflargesoftwaresystems.Howeverforcertaintasks,such
asdebugging1,itissensibleandnecessarytosupportthewhite-boxmodel,inorder
tobeabletoinspecttheinternaldatastructuresofaco-module.
Actuallytheideaofdeviatingfromtheinformation-hidingprincipleincare-
fullycontrolledsituationsisnotnew,andwasalsoenvisagedbytheMONADS
statedevelopers.ofaApersistentproblemmodulethatwascouldencounteredbecomeininconsistenttheMONADSbecausesystemofanwaserrorthatinthethe
implementation.Themodulecouldbecomecompletelyunusable.Sucherrorsin
thetem.Tstateoofsolveathis,modulethegenerallyrepairmancannotmodulebefixedconceptin2ahasstrictlybeenproposed,information-hidingpostulatingsys-
amodulethatcanfixconsistencyproblemsbydirectlymodifyingtheencapsulated
dataofanothermodule.HoweverthiswasneverimplementedinMONADS.
WiththedesignofcompositemodulesdescribedbyaCo-moduleTable,itispos-
sibletosharetheprivatedataofe.g.theapplicationco-modulewithadebugging
co-module(cf.entries2and4inFigure5.3).Theapplicationandthedebugger
co-moduleoperateonthesameprivatedata.InFigure5.5thisisillustratedby
different“modules”thataccessasinglepieceofdata.
Co-ModuleDebugCo-ModuleApplicationshareddataprivate

Figure5.5:Severalco-moduleswithaccesstocommonprivatedata

stillDirectforbidden.accessThetotheprivateprivatedataisdataonlywithoutdrawnusingseparatelythetointerfaceillustrateofathatco-modulealltheseis
co-modulesoperateonasingleprivatedataarea.Theinternalrepresentationof
ainvocationco-moduleismechanisminvisibleistousedtheforclientbothofawhite-boxparticularandco-module.black-boxTheco-modules.samemethod
in1thisOthercontext.aspectsofdebugging,suchascontrollingtheexecutionthroughbreakpoints,areignored
in2This[150],ideawhichisactuallydescribesquitehowold,tobutstructurehasnevercomplexbeensystemspublished.withtheTheconceptsonlyofwrittenTimord.escriptionis

5.2NewOperatingSystemStructuringApproach

147

5.2.6Co-ModuleUsebytheKernel
Ifoutthedelegatedkernelneedsfunctionalitytouse,aitmayco-moduleitselfofcallamethodscompositeofmodulecompositeinordermodules.toFcarryor
theexamplepagethefaultkernelresolutioninvokesrequiredmethodstooftheimplementpagetablevirtualco-modulememory.inordertoinitiate
Thekerneldefinesthemeaningofcertainco-moduleswhichthekernelneedsfor
allcorrectapplications.co-moduleUsingtobewell-knowndeterminedeasilyco-module.Additionallynumbersforthethiskernelpurposedefinesallows(atleastthe
partially)theinterfaceofco-modulesrequiredbythekernel.Theflexibilityofthis
structuringapproachisbasedonthepossibilityofimplementingtheinterfaceof
suchco-moduleswithdifferentdatastructuresanddifferentalgorithms,depending
onIntheordersemanticstoandimplementperformanceinter-modulerequirementscalls,theofthekernelapplication.accessestheCo-module
Tuseableadirectlyco-module,i.e.toitsaccessstructurethisisstructure,actuallybecausespecifiedthatbythewouldkernel.requireThekernelanothercannotaccess
totheCo-moduleTableandwouldresultinanendlessloopofinter-modulecalls.

Co-ModulesBracketing5.2.7Thecompositemoduleconceptcanbeorthogonallycombinedwiththebracketing
conceptdescribedinchapter4.Eachco-modulecanbeindividuallyqualifiedby
alistofqualifyingmodules.TheQualifierListManagerforaco-moduleisitself
usuallyacompletecompositemodule.Thecapabilityforthequalifierlistassociated
withaco-moduleisstoredinanadditionalfieldintherespectiveco-moduleentry,
asillustratedinFigure5.6fortheapplicationco-module.
ModuleCompositeModuleCompositeCo-ModuleTableCo-ModuleTable

ManagerCo-ModulecodeManagerQualifierListcode
dataprivateofapplicationcodeApplicationlistofbrackets

Figure5.6:Compositemodulecontentincludingbracketsupport
Inthediagrammanydetailsthatarenotrelevantinthecontextofbracketing
areManagerleftout,toe.g.insertthetheexistencereferenceoftoothertheQualifierco-modules.ListItistheManagertask,butofthethecontentCo-moduleof
thequalifierlististhencontrolledbythequalifierlistmodule.

148

Chapter5ModelforCompositeModules

Thegeneralbracketingprinciplesapplytoeachco-modulewithoutchange.Both
call-inandcall-outbracketmethodsarepossible.Theinvocationofthebracket
methodsiscoordinatedbytheinter-modulecalloperation.
Bracketsfine-grained,mayfreelybeappliedprogrammabletoanyaccessinterfacecontrolmethodofsystem.aOtherco-module,security-relatedprovidinga
conceptstime-restrictedwhichaccesscanbeordecoys,implementedarereadilyusingapplicablebrackets,tosuchasco-modules.accessmonitoring,

5.3DelegatingFunctionalitytoModules

ThedelegationofOSfunctionalitytoco-modulesassociatedwithapplicationsis
onlymanysensiblefunctionsifthisthatwerefunctionalitytraditionallyrelatesthetothetaskofapplicationthekernel,itself.suchThisastheappliesman-for
threadsagementofwithintheavirtualprocess.memoryCo-modulesrepresentationmayalsoofbeausedmodulefororotherthepurposes,managemente.g.forof
managingHoweverthethisreplicationstructureisofanotmodulesuitableinforaresourcedistributedallocationsystem.problems(e.g.main
memoryallocationandCPUscheduling)andfordevicedrivers.Separate,central
compositemodulesaretheappropriatesolutionforsuchcoordinationproblems.
Bothcentralanddecentralpoliciesneedtobesupportedbyatrulyflexibleker-
nel,delegateaccordingbothtocentraltheandproblemdecentraltobepoliciessolved.touser-levelAccordinglyitmodules,mustbeotherwisepossibletheto
advantagesMicrokernelsofthesupportseparationonlythebetweendelegationmechanismofcentralandpolicypoliciesisoutsidesacrificed.thekernel,
ininthetheuseformofofunsuitableuser-levelservices.implementationThelackofstructuressupportforforthedecentralOS-relatedpoliciesfunctional-results
ityextensibleimplementedsystems.attheuserAdditionallylevel,thewhichsecuritymakesandithardprocesstoimplementmanagementflexibleproblemsand
sarilycausedbycomplicatedtheuseofforthebothout-ofthe-processimplementormodelofamakeservicetheandofanimplementationapplication.unneces-
Theappropriatecompleteuser-leveldelegationmodulesofleavespolicy-relatedonlyasmallfunctionalitynumberoffromessentialthekernelmechanismstothe
ofinthethekernel.currentMostmoduleormechanismstheareinvocationrelatedoftoanotherthemodule,managementbutofthethekernelenvironmentisalso
ultimatelyresponsibleforhandlinginterrupts.Nomatterhowthekernelisentered,
itoftenneedstorelyonuser-levelmodulestocarryoutitstasks,suchasquerying
thepagefromappropriatediscinqualifierreactionlisttoamodulespagefault.incaseofaninter-modulecallorloadinga
Thesmallnumberofmechanismsimplementedbythekernelgreatlysimplifies
thetheaccessinter-modulecheckscallintheoperation,kernel.Thewhichkeyplaysaprotectionpivotalrolemechanismintheisentireimplementeddesign.in
ontheDelegationoverallofOSkernelstructure.functionalityThekerneltoisuser-levelsimplified,modulesbutinhasreturnagreattheuser-levelinfluence

ConceptsRelated5.4

149

partsoftheOShavetoassumemoreresponsibility.Thisshiftisnotsimplyacode
reorganisation,butanopportunitytoprovidepreciselythefunctionalityrequired
bytheapplications.ThesemanticgapbetweenanapplicationandtheOSmaybe
greatlyreducedbyprovidingimplementationsoftheOS-relatedco-modulesthat
areclosetotherequirementsoftheapplication.Theuniformmodulestructure
providesthenecessarybasis,includingflexibleprotectionviabrackets.
Applicationsthemselvesdonothavetochangetheirstructureifthedefaultim-
plementationofthevariousco-modulesimplementingtheOSfunctionalityissuit-
able.Howeverthedesignerofasoftwaresystemhasthefreedomtoreplaceco-
modules(underthecontroloftheCo-moduleManager)ifrequired.Suchoptim-
isationsarenotpossibleinmostotherOSdesigns.

ConceptsRelated5.4Althoughgrammingsomelanguagesapparently(e.g.similarattributesinstructuringTimor[142,techniques143])existandinthemiddlewareareaof(e.g.pro-
bracketcapabilitiesinOpsis[79]andinterfacesinCORBA[209]),evenasuperfi-
cialulesinanalysissuchaofwaythesethatOSrevealskernelthattheyfunctionalityaretotallycanbeinadequatedelegatedfortothem.structuringmod-

Microkernels5.4.1nelThemostapproach.popularTheattemptabsolutetocodereducesizetheofsuchkernelakernelfunctionalitymaybesotiny,farbutisitthehasmicroker-several
structuralintroducesparallelproblems.activitiesOneiswhichcausedbynormallyfollowingdonottheleadout-oftohigher-processmodel,parallelism.which
theHowevercentralisedthemostdelegationinterestingtoasingleproblemserverinperthisfunction.contextistheWhilethelimitationsdelegationcausedaimsby
todomofsupportthethepolicyseparationimplementationofmechanismbyandsupportingpolicyonly,italsodelegationseverelytolimitscentraltheservers.free-
anThusattemptthetomicrokernelsolvetheapproachstructuringintroducesproblemsstructuringencounteredinproblemsatmonolithictheuserkernels.levelInin
contrastcompositemodulessupportdifferentpoliciesfordifferentmodules.

Exokernels5.4.2Basedontheexperiencewithmicrokernels,newerkerneldesignshavebeende-
ofvelopedthemostthattryradicaltoavoidapproachescertainisthedisadvantagesexokernelofthedesign(cf.microkernelsection3.10),approach.whichOne
plexingintendstomechanism.reducetheThiskernelincreasesfunctionalityflexibilityfurtherand,alsoprovidingextensibilityonlya,butresourceintroducesmulti-
portnewmixingstructuralglobalproblems,andlocalbecauseresourcetheallocation.multiplexingmechanismImplementingdoesafilenotsystemeasilysup-has

150

Chapter5ModelforCompositeModules

proventobedifficult,becauseeventhemechanismsforcooperationhavebeenal-
mosteliminated.SPEEDOSsupportssuchcooperationbytreatingco-modulesas
tionfirst-classoracentralobjects.moduleTheinkernelorderusestoeithercarryaoutitsco-moduletasks.associatedwiththeapplica-
Theexokernelapproachandthesoftware-basedprotectionmodel(e.g.asimple-
mentedintheGo!OS[170])arepartofanevolutionultimatelytriggeredbythe
entirelymicrokernel,replacingmodel.itwithTheapurelydevelopmentuser-leveldirectionOS.istowardseliminatingthekernel
Buteffectivelytheoppositeofthisistrue:theresultisasystem(abovethealmost
theOSnon-existentandits“kernel”)applications.consistingThisofbecomesonlyakernelobviousatintheuseroperatinglevel,wsystemshichbasedincludeson
thesoftware-basedprotectionmodel:everythingrunsinkernelmode.Because
thisistoomuchprivilegeformostcode,theactualaccessesmustbechecked,
usingcharacterisedcodeasverificationmonolithictechniques.(includingThisevenkernelthestructureapplications)couldwithbeaprovocativelyfine-grained
protectionsystem.Thistendencytoeliminateallstructuralsupportfromthekernel
willinsteadonlyofmakesimplerthe.TheimplementationproblemswithofboththefiletheOSsystemandtheimplementationapplicationsandharderthe
crudeprocessschedulerimplementationinexokernelsillustratethis.
Whiletheaimsofmicrokernelsandexokernelsintendtoseparatemechanism
andhere.policy,Compositetheyfollowmodulesaareintendedfundamentallytobeadifferentsoftwareapproachstructurefromthatthathelpsproposedachiev-
ingaflexibleandextensiblesystem,whereassuchstructuralaspectsarerelatively
unimportantinmicrokernelsandexokernels.Moreovertheprotectionmechanisms
includedimplementedintheseatthekerneluserleveldesignsareusuallyweakrequiresandtheadditionalprotectionchecksforOSwhichfunctionalitymustbe
approachexplicitlytoprogrammedprotectionininthesystemsOSbasedservices.onThismicrokernelsoftenorresultsinexokernels.aninconsistent

Summary5.5

hasThecreatedintroductiontheofaopportunitynewtostructuringdefineco-modulesmechanismforwhichdefiningimplementcompositedecentralisedmodules
functionality.Incombinationwithdelegationofresourceallocationtocentralmod-
ules,thisallowsthekernelcodetobereducedtothedegreethatitonlyimplements
policy-neutralmechanisms,e.g.forprocessormemorymanagement.
HoweverthemostimportantresultintheSPEEDOScontextisthatitispossible
todelegateallpolicy-relatedkernelfunctionalitytouser-levelmoduleswithout
sacrificingtheflexibility,extensibilityorsecurityofthesystem.Thesupportfor
delegatingapplication-specificpolicieseffectivelyisthekeytotheimprovedflexib-
ilityofthekernelandoftheapplications.
Whilemanysystems(includingmicrokernels)haveembracedtheprincipleof
separationofmechanismandpolicy,theirlimitationtoacentralisedimplementa-

Summary5.5

151

tionstrategyhaslimitedthegain.Certaincentralcoordinationmodulesarenever-
thelessnecessarytomanageresources,suchasCPUtime,mainmemoryandI/O
bandwidth.Theco-modulesaccessthecentralresourcemanagementmodulesas
requiredtoimplementtheco-modulefunctionality.
Co-modulesareseparatemodules,whichgenerallyadheretotheinformation
hidingprinciple.Itisalsopossibletocreateco-modulesthathavedirectaccess
totheprivatedataofanotherco-module.Theexistenceofsuchco-modulesisun-
usualandgenerallylimitedtosupportoperationssuchasdebugging,wheretheco-
modulehavingsharedaccesstotheprivatedataofanotherco-modulehascomplete
knowledgeaboutimplementationdetails,includingtheinternaldatastructures.
TheCo-moduleManagerisultimatelyresponsibleforcontrollingthecreation
oftheco-modulesbelongingtoacompositemodule.TheCo-moduleTablecan
bechangedatrun-time,assumingappropriatesynchronisationbytheCo-module
Managerandtheclientmodules.Thiscreatestheopportunitytotunetheper-
formanceofanapplicationatrun-time,byreplacingtheimplementationofaco-
moduleatrun-time.Thefreedomtomixandmatchco-moduleimplementations
forthedifferentfunctionalitydelegatedtoacompositemodulegreatlyenhances
theflexibilityandextensibilityofthesystem.
Compositemodulesareanidealcomplementtobracketing.Togethertheyallow
bothflexiblemodulestructuringandahighlevelofprotection.Thisenhanced
moduleconceptisthebasisfortheSPEEDOSdesignwhichconsistsof

a)akernelthatimplementsasmallnumberofsecurity-criticalmechanismsand

b)user-levelmodules,whichimplementboththecentralanddecentralpolicies
applications.theand

Inthenexttwochapterswedescribe(a)theSPEEDOSkerneldesignand(b)an
outlineofapossiblesetofOSmodules,implementedasuser-levelmodules,which
couldtogetherimplementaSPEEDOSoperatingsystem.

152

Chapter

5

Model

for

Composite

Modules

6Chapter

DesignoftheSPEEDOSKernel

153

ismsBuildinghaveonbeentheresultsproposedofinthechaptersurvey4inandchapterchapter3two5.newTheseOSmechanismsstructuringaremechan-used
inthedesignoftheSPEEDOSkernel,whichispresentedinthischapter.
designThebasicdecisionskernelpresenteddesigninphilosophythischapterisoutlinedaretheinsectionconsequences6.1.ofThetheindividualchosen
designphilosophy.Thereishoweverstillmuchroomforshapingtheappearance
ofandtheextensibleresultingcompletemechanismssystem,insteadofbecausedictatingtheakernelfixedOSfocusesonfunctionalityproviding.flexible
Section6.2describestheroleofthekernelintermsofitsapproachtopersist-
ware.ence,itsSectioninterface6.3styleintroducesanditstheusemainofmodulekindsofobjectsinterfacesofwhichprovidedthebyukernelser-islevelaware.soft-
Section6.4explainshowthekernelsupportsapersistentvirtualmemoryandout-
linesexplainsthethevirtualorganisationmemoryandstructureinvocationandofimplementationmodules.Insectionprinciples.6.6theSectionkernel6.5
designapproachwithrespecttoprocessandinterruptmanagementisdescribed.
Section6.7explainshowcodeisorganisedintocodemodulesandhowlibrar-
iesprovidinggenerallyusefulfunctionalitytomodulesareintegrated.Protection
mechanismsarepresentedinsection6.8.Thechapterconcludeswithabriefdis-
cussionofdevicedriversandhowthesystemcanbebootstrappedandcloseddown.
SincemostOSfunctionalityisdelegatedtocompositemodulesandco-modules,
itisimpossibletodescribethekernelwithoutoutliningthetasksoftheuser-level
theymodules.areoftenManyduetodetailedlimitationsimplementationofthecurrentissuesareprocessorignoredinarchitectures.thischapter,Somesinceof
thesedetailswillbetreatedinthefollowingchapters.

6.1PhilosophyDesign

IntheoverviewofOSconceptsinchapter2itwasmentionedthatinthedesign
ofanOStherearenumerouschoicestobemade,whichallindirectlyaffectthe
propertiesoftheresultingsystem.Thedesignshouldbeconsistent,whichrequires
well-matcheddecisionsinvariouspartsofthedesign,notalargenumberofindi-
decisions.implementationindependentvidual

154

Chapter6DesignoftheSPEEDOSKernel

Theusualapproachistoformulateadesignphilosophythatprovidesaguideline
formakingthedetaildecisions.Bytheirnature,suchdesignphilosophiesarevery
general,sinceitshouldnotitselfbejustasummaryofalldecisions.
ThedesignphilosophybehindSPEEDOScontainsthefollowingkeypoints:
•Itshouldbepossibletoachieveaveryhighlevelofsecurity,whichmeansthat
itshouldbepossibletosolvetheprotectionproblemsencounteredinother
operatingsystems(cf.chapter3).
•Securityismoreimportantthanefficiency.WhileanOSshouldbeefficient,a
certainoverheadisintrinsicallypartofahighlysecuresystem.
•Thekernelshouldnotimplementspecificsecurityorresourcecontrolpolicies.
ThisisthedutyofOSmodulesthatareinprincipleindistinguishablefromap-
plicationmodules.Thekernelshouldprovideasfewmechanismsaspossible.
Thereshouldbeonlyoneflexibleprotectionmechanismthatappliestoall
modules,regardlesswhethertheyimplementOSorapplicationfunctionality.
•Thekernelshouldbecapableofsupportingdifferentsecurityandresource
controlpoliciesconcurrentlyinasinglesystem.Thisshouldnotrequirecom-
promisesthatfavouracertainpolicy.
•TheentireOSshouldbeasextensibleandflexibleaspossible,supportingre-
placementofOSfunctionalitywhilethesystemisrunning,withoutrequiring
asystemrebootorothersimilarservicedisruption.
•Auniform,persistentvirtualmemoryshouldreplacetheseparatefilestore
andvirtualmemoryimplementation.Processesarerepresentedinpersistent
virtualmemoryandthusarealsopersistent.
•Theinformation-hidingprincipleappliestothemoduleswhichcomprisethe
user-levelpartoftheOSandtheapplications.Thiseliminatesthedependency
onspecialdatastructuresandmechanismsinthevariouspartsoftheOS.
•Thedesignshouldbeadaptable,suchthatfunctionalitycurrentlyonlyfound
inspecialisedoperatingsystemsmaybeimplemented(e.g.thescheduling
OS).real-timeaforalgorithmsThedesignphilosophyfocusesonthekeyissuesofprotection,security,uniform-
ity,flexibilityandextensibility.TheseareallimportantaspectsrequiredforanOS
whichcanmeetthechallengesposedbythewidespreaduseofsoftwaresystems.
Todaysecurityisanimportantissue,giventhesecuritythreatscausedbyconven-
tionaloperatingsystemsandapplicationsusedfortheeverydaywork(including
Webbrowsers,whichtransformmanypreviouslylocalprotectionproblemsorsoft-
wareerrorsintosecurityholesthatmaybeexploitedovertheInternet).
Akernelfollowingthesedesignprinciplescanbeusedtoimplementabroad
rangeofoperatingsystems.Ineffectthedesignoftheuser-levelpartoftheOS

6.2RoleoftheKernel

155

determinestheprecisepropertiesofthecompleteOS.Thisaddressesthegen-
eralcriticismofoperatingsystemstructureformulatedbyWulfetal.in[306](cf.
section5.1.2),whichisstillapplicabletocontemporaryoperatingsystems.

6.2RoleoftheKernel
Sofarin-processverylittlemodel.Inexperiencethesurvey,existsthehowonlytosystemsstructurewhichaminimalfollowthekernelin-processfollowingmodelthe
and(seesectionsupport3.8),persistentfromwhichmemorysomearedesignMONADSprinciples(seeforsectionSPEEDOS3.3)andweretakenGrasshopper1.
BothMONADSandGrasshopperareimplementedwithamonolithickernel,
andwhichdeviceincludesdrivers.allcoreInOSGrasshopperservices,theresuchisasanscheduling,optionalvirtualmechanismmemoryforhandlingsupport
pagedonedfaultssuccessorbyuser-levelprojectofcode,butGrasshopperthe,kernelCharmisstill[114],largeandattemptedcomplex.toAnimplementaban-a
microkernelforaGrasshopper-likeOSandprovidedsomeinspirationforSPEEDOS,
butthesolutionsinthisthesisarefundamentallydifferent.

ersistencePernelK6.2.1AdifferencetomanyotherkernelsforpersistentsystemsisthattheSPEEDOSker-
nelitselfisnotpersistent.Thereasonisthatthestateofallobjects(modulesand
stateprocesses)informationisassumedtomaintainedbepartintheofthekernelispersistenteitheravirtualcopyofmemorydata.Allfromtheadditionalper-
sistentvirtualmemoryorcanbederivedfromdatastoredinthepersistentvirtual
memory.ThisaspectoftheSPEEDOSkernelissimilartoKeyKOS(cf.section3.2).
Thiseliminatestheproblemofrepresentingthekernelinvirtualmemory.The
kernelsimplyexistswhileaSPEEDOSsystemisrunning.Correspondinglythein-
Theterfacebehaviourpresentedofbythethekernelkernelmayisnotdifferentbetocontrolledtheorinterfacemodifiedpresentedbyaddingbyabracketsmodule.
toit.ThemostfundamentaldifferenceisthatallobjectsinSPEEDOShaveaglob-
allymoduleuniquealwaysidentifieruses,thewhereaskernelofthethekernelnodehasonnowhichitidentifier.executes.Acurrentlyexecuting
Persistentkernelsinadistributedsystemwouldneedtocommunicatewitheach
otherinordertoexchangeinformatione.g.aboutmodulesandprocessesmigrating
betweennodes.Forasmallkernelthiswouldneedtobedelegatedtouser-level
modulesanyway.Thebettersolutionistoleavesuchcommunicationcompletelyto
user-levelmodulesandletthekernelworkonlyonlocallyavailableinformation.
1LargepartsofthemoduleterminologyhavebeentakenfromGrasshopper,sincethenotions
usedsystem,inandMONADStheacurrentlyretodaywoftenell-acceptedmisleading.notionsThehavereasonbeenforre-invthisentedisthatindependentlyMONADS.isThisaquiteledtoolda
terminologymismatchasthedefinitionsoftendiffersubtlyorcompletely.

156

Chapter6DesignoftheSPEEDOSKernel

InstructionsernelK6.2.2Thekernelinterfacepresentedtothemodulesisintheformofkernelinstructions.
ture.TheyIncompriseotherankernelsextensiontheseofaretheofteninstructionreferredsettoasdefinedsystembythecalls,butprocessorforSPEEDOSarchitec-
theInthisinstructioninterpretationmetaphortheiskernelconsidered(asseentobebyaclearermodule).implementsanaugmented
virtualmachinethatdefinestheenvironmentofthecurrentprocesses.Thekernel
instructionsgenerallyeithermodifyorquerythestateofthisvirtualmachineorthe
contentofvirtualmemory.Mostkernelinstructionsarequitesimple,butcritical
forSimilarlyprotectionto(i.e.normaltheyprocessorresembletheinstructionsmicrocodethereofaistheMONADSchanceprocessorthata[3,kernel4]).in-
memorystructionthatmayisnotcauseancurrentlyinterrupt,presente.g.inmainbecauseitmemory.accessesTheawordsolutionofintheSPEEDOSvirtual
iscessissimilarnottothemodifiedsolutionatall,forsothatprocessorinterruptsareinstructions:handledthestatelogicallyofthebeforecurrentthekernelpro-
Thereinstruction.arenoThekernelprivilegedinstructionkernelisinstructionsre-triedafterthattheareonlyinterruptavailablehasbeeninahandled.special
“mode”.Allkernelinstructionsmaybecalledbyanyprocessandwithinanymod-
ule.requiresHoweverpassingasomecapabilitykernelwithinstructionsaccessarerightswhichprotected,indeterminethesensewhetherthatthetheirkerneluse
stateinstructionofthemayvirtualbemachineperformedatinfluenceall.Thetheprecisemetarightsinmeaningaofcapabilityakernelandtheinstruction.current
Somesecurity-sensitivekernelinstructionsmustbepresentedaspecialkernel
tions,capabilitybut.Theotherwiseaccesstherightscapabilityrepresentplaysthenorolepermissioninthetoperformedinvokeparticularoperation.instruc-
thatEachkernelintermediateinstructionresultsarenotrepresentsvisibleantoelementaryuser-level,atomicmodulesandoperation,processes.whichThismeansis
importantforinstructionsthataccessand/ormodifyprotecteddatastructuressuch
ascapabilities,whichmustbealwaysconsistent.Asummaryofallinstructions
usingdescribedinhuman-readablethischapternamescanbe(e.g.textfoundinstrings)appendixasA.operandsTheforkernelkerneldesigninstructions.avoids
Themanagementonlynamesofthatarehuman-readablesupportednamesbytheisleftkernelarecompletelyidentifierstoinuser-levelcapabilities.modules.The

6.2.3UseofModuleInterfacesandDataStructures
theThekernelSPEEDOScankernelinvoke.expectsThisallowscertainthemoduleskerneltotoexistdelegatewhichpolicyprovidedecisionsmethodstouser-that
levelunsuitableOSinmodules.thecontextSuchofmodulesaminimalmayalsokernel.carryTheoutinvocationcomplexofoperationsmethodsthatbytheare
kerneliscalledforcedmethodcall,sincethecurrentmoduledoesnotdirectlytake
notpartalterandthethestatereturnofthevaluesarecurrentuserinterpretedmodule,bythebutkernel.side-effectsAforcedmaybemethodvisible.calldoes

6.3ModuleCapabilitiesandObjectTypes

157

Inordertoimplementthebasicsupportformodulesandprocesses,thekernel
directlyaccessescertainwell-defineddatastructuresstoredinthepersistentvirtual
memory.Thisallowsthekerneltoworkonpersistentdatawithoutitselfneedingto
bepersistent.Itisnotpossibletoencapsulatetheaccessestothesedatastructures
inaco-module,sincethesedatastructuresdescribekernel-supportedobjects.
ThespecificationofbothmethodinterfaceswhichimplementOSfunctionality
anddatastructuresaccesseddirectlybythekernelarepartofthekernelspecific-
ation.ThedescriptionhowthemethodstowhichOSfunctionalityisdelegated
achievetheirtaskisdeliberatelykeptgeneralinthischapter,inordertoallowa
largeimplementationvarietyinactualmethodimplementations.

6.3ModuleCapabilitiesandObjectTypes
Thekerneldistinguishesbetweenthreekindsofmajorsoftwareobjects:filemod-
ules,processesandcodemodules.Alltheseobjectsarepotentiallypersistentand
arestoredincontainersinthevirtualmemory.
Amodulecapability(sometimesabbreviatedasModCap)isaprotecteddatastruc-
turewhichprovidesaccesstothecontentofacontainer.Itsfullstructureisde-
scribedlater.Itcontains(seeFigure6.1)theuniquevirtualaddressofthecon-
tainer,anindexfield,atypefieldwhichdetermineshowthekernelshouldinterpret
thecontainer’scontents,accessrightsandotherprotectionrelatedfields.

Container#IndexTypeAccessRights...

Figure6.1:Simplifiedstructureofamodulecapability
Acontainerisaverylargefixed-lengthstorageareawithcontiguousvirtualad-
dresses.EachkindofContainersobjectcanisbedescribedcomparedbytoadatafilesinstructureconventionalwhichissystems.directlyaccessible
tothekernel(cf.section6.2.3):
•Afilemodule(i.e.anindividualco-module)isdefinedintheCo-moduleTable
(seeidentifierchapterconsists5).Itofcanitsbeuniqueaccessedcontainerviaafilenumbercapabilityand,initswhichindexinthetheuniqueCo-
able.Tmodule•Aprocessbeginsitslifeasafilemoduleinwhichaspecialapplicationco-
moduleisloaded,theThreadManager.TheThreadManagercreatesand
themaintainsthreadsaThreadassociatedTablewith,awhichprocessisdirectlyandallowsaccessiblethetokernelthetokernel.locateItthedefinesstack
ofeachthread.Thestacksofrelatedthreadsareheldinasinglecontainer.A
threadconsistscanofthebeuniqueaccessedviacontainerathreadnumbercapabilityand,aninindexwhichintothetheuniqueThreadTidentifierable.

158

Chapter6DesignoftheSPEEDOSKernel

•isAcodeexecutablemodulealsoobjectbeginscodeitsthatlifeisasafilegeneratedmodule,byaincompilerwhichtheordatacomposedstructureby
aTablelinker,.whichTheCodedefinestheManagercontentofco-moduleaiscompositeresponsiblecodeformodule.updatingWhenthetheCodeCode
theManagercontainercreatesnumberanewisCodeextendedTablebyentryan,itindexreturnsintoathecodeCodeTcapabilityable.Theinwhichindex
selectsaparticularmethodlistfromtheCodeTable,aswillbedescribedlater.
structingThesethreesoftwaresystemskernel-supportedinSPEEDOSobject.Ftypesorsucharethesoftwarecoresystemsbuildingitisblocksalsoforhelpfulcon-
toSPEEDOSprovidearelibrariesvariantsofoffileuniversallyandcodeusefulmodulesfunctionsto(cfwhich.sectiontheprivate2.8.7).dataLibrariesoftheirin
clientmoduleismadeaccessible.Thedifferencetoordinaryfileorcodemodules
isWhenindicatedabyprocessabitinexecutesthecoderespectiveintheCodecontextTableofaentryfile.module,boththecodeand
theencapsulateddatastructuresareaccesseddirectly.

MemoryVirtualersistentP6.4InSPEEDOSthevirtualmemorysupportincludesthefunctionalityofboththe
memorycomputationalprotectionmemorymechanismsandthe[238,persistent1]foundmemoryin,mosteliminatingothertheoperatingduplicationsystems.of
largeAlthoughpersistentthevirtualkernelismemorynot.itselfThekernelpersistent,insupportsprovidesthebasicorthogonalsupportforsegmentationavery
andpendentpagingofpagemodel(cf.boundaries,sectionand2.2.8mayandbeeither[134]).smallerSegmentsorlargerarethanacompletelypage.inde-
Inpracticethismaydegeneratetoapagedsegmentationmodeliftheunderlying
hardwareprovidesinadequatevirtualmemorymanagementsupport.
ForcertainpartsoftheSPEEDOSdescriptionthesupportofvariable-sizedseg-
partsmentsthe(withaccessinterpretationrightsoftherelatingvirtualtothememorywholeasasegment)collectionisofrelevantpagesandwithforotherfixed
size(andlessemphasisonaccessrights)ismoreappropriate.

Containers6.4.1Thebasicunittowhichtheorthogonalsegmentationandpagingmodelisapplied
isnectedthetocontainerthe.Internet)Containersandcanhavebelocatedworld-wideonuniquedifferentaddresses.SPEEDOSAnodescontainer(e.g.con-is
fundamentallypersistent,i.e.itexistsuntilitisexplicitlydeleted.Eachcontainer
hasAancontainerowner,isawhichlargeisgenerallyfixed-sizethestorageuniqueareauseronaidentifierpersistentofitsmedium.creator.Spaceon
discneedneedanonlyefficientbeallocatedrepresentationforpagesoftheirwhichVirtualactuallyMemorycontainPageTdata.ableLarge(VMPT)containerswhich

VirtualPersistent6.4Memory

159

systemdescribeshavethediverseallocatedpagesrequirements.inaThecontainer.managementThevariousofaVMPTcontainersisinthereforeaSPEEDOSorgan-
isedviaaco-module,whichimplementsanappropriatepagetableorganisationfor
theirInthisindividualdescriptioncontainerthe.sizeTheofastructurecontainerofaisVMPTisassumednottoknownbe2to64thebytes,kernel.which
shouldfeaturesbesuchlargeassparseenoughtodatastorestructurestheprivateareused.dataItofareliesratheronanhugemodule,implementationevenofif
theThevirtualvirtualmemorymemorycanmanagementholdalargethatcannumberofefficientlycontainers.representtherequiredVMPT.

agingP6.4.2Avirtualaddressconsistsofauniquecontainernumberandanoffsetwithinthis
incontainervirtual,asmemoryshown,andinareFigurealigned6.2.withEffectivelythe264bytecontainersvirtualareaddressplacedboundaries.consecutively

NumberContainerContainerinOffset

Figure6.2:Logicalstructureofthepagedvirtualmemoryaddress

Thekernelmanagesthesubsetofthevirtualmemorythatiscurrentlypresent
inmainmemory,describedbytheMainMemoryPageTable(MMPT).TheTrans-
lationLookasideBuffer(TLB)misshandlerisimplementeddirectlybythekernel
withoutusingco-modules,becausetheTLBsincurrentprocessorimplementations
aretoosmalltobemanagedeffectivelybyuser-levelcode.Additionallythecostof
aTLBmissresolutionbyuser-levelcodewouldseverelylimittheperformanceofa
SPEEDOSsystem,withoutnoticeablyimprovingprotectionorpolicy-neutrality.
IftheTLBmisshandlerdetectsapagefault,itinvokesafixedmethodofacent-
ralpolicymodule,theContainerDirectory.TheContainerDirectoryisoneofthe
standardmodulesknowntothekernel(cf.section6.2.3)andhastheresponsibility
ofresolvingthepagefaultincooperationwiththePageTableManagerco-module
(forwhichthekernelpassesamodulecapabilitytotheContainerDirectory)ofthe
containerinwhichthefaultoccurredandthedevicedriversforthestoragemedia.
TheMMPTisaglobalresourceforallprocessorsonanode.Itmustbeup-
dated(indirectly)onlybytrustworthymodulesimplementingthevirtualmemory.
AddingorupdatinganentryintheMMPTispossiblebyusingthekernelinstruc-
tionmap_page.SimilarlyexistingentriesfromtheMMPTcanberemovedwith
theinstructionunmap_page.Theseinstructionsareprotectedbyakernelcap-
ability.DecisionsaffectingtheMMPTareusuallydelegatedtoaper-nodeMain
MemoryDirectorymodule,whichisresponsibleforthemainmemoryallocation
policyincludingthepagediscardstrategy.
Page-basedprotectionplaysarelativelyminorroleandisgenerallyusedonlyfor
implementingthemultiplereader/singlewriterconsistencyprotocol.

160

Chapter6DesignoftheSPEEDOSKernel

Segmentation6.4.3Segmentsfulfiladifferentrole.Theygroupvariable-sized,relatedinformationinto
acontiguousdatastructure.The64sizeoftheinformationinasegmentcanrange
fromasinglebytetoalmost2bytes(allowingforadministrativeoverheads).
EachSegmentssegmentmaynotinspanprinciplecontainers.consistsofthreeparts:
Normalthatdata:canbeTherepresentedrepresentationbytheofusualthedataprogrammingstructuresinalanguagecontainertypes.The(integers,data
thanfloatingreferencespointtovalues,otherdatacharactersorstructures.morecomplicateddatastructures)other
Pointers:Anabbreviatedformofreferencestoothersegmentsinthesamecon-
tainer.Withinacontaineritissufficienttouse(protected)referencestoa
segmentcapabilitywhichdescribesthesegment(cf.section6.4.4),including
thewithinaccessasegmentrights.arePointersunprotectedareandreferencesmaytobestoredsegmentsintheasanormalwhole.dataOffsetspart.
Moduleulecapabilitiescapabilities:Renforceseferencesthetootherinformation-hidingcontainers.Theprinciple,i.e.interpretationtheyofactuallymod-
referdetailstoaaremoduledescribedandinnotsectiondirectly6.8.1.tothesegmentsstoredinitscontainer.The
Thisformofasegregatedsegmentisavariationoftheusualsegregatedseg-
ment[126]thatdistinguishesbetweendataandpointers.SPEEDOSsupportstwo
segment.fundamentallyEachareadifferentconsiststypesofofanreferencesarbitraryandnumberthusofusesthethreerespectivesuchareasfixed-sizeina
tions.elements.TheOnlycontentstheofnormalthepointerdatapartandismoduleaccessiblecapabilitybythepartsnormalcanonlyprocessorbeaccessedinstruc-
thatand/orcontainsmodifiedallbythreecertainareas.kernelInthisthesis,instructions.moduleInFigurecapabilities6.3aandsegmenttheismoduleshown
capabilityareaofasegmentaregenerallydrawnindarkgrey.

datanormaloffsetpointers

capabilitiesmodule

Figure6.3:Structureofasegregatedsegment
andFortheaddressingindividualpurposesentriesaretheidentifiedboundariesbytheirbetweenoffsettheindifferentthesegareasment.areThisignored,does

6.4MemoryVirtualPersistent

161

notknown,violatebutthetheircontentinformation-hidingisnotdirectlyprinciple,accessible.becausePonlyointerstheandsizeofmoduletheelementscapabilitiesis
areregardedaselementary,opaquedatastructureswithfixedsize,whichallows
access.andallocationspaceefficientSPEEDOSenforcesnoparticularsegmentstructuringfortheprivatemoduledata
2withinrepresentathecontainerprivate.dataTheofaprogrammermodule,isfromfreeatosingleuseanysegmenttonumberahighlyofsegmentsstructuredto
Thecollectionreasonofwhysegmentspointersthatrefermaytoonlyeachreferenceotherdatathroughinthepointers.samecontaineristhat
thisisolatescontainersfromeachother,makingthemindependent,closedentities.
Thisaccordsforceswithdatathewhichbelonginformation-hidingtogethertoprinciple.beplacedinFurthermoreasingleitiscontainerencouraged,whichto
Itgrouphasalsoinformationpracticalwithaspects.similarLimitingprotectiontheplacerequirements.wheredirectmemoryreferences
maybestoredmakesgarbagecollectioninadistributedsharedmemorysystem
feasible.reachable,andGarbagethiswouldcollectionbeneedspracticallytodetermineimpossiblewhetherforaunconstrainedcertainsegmentreferences.isstill
tems,Howeverbutalsogarbagewithcollectionremovablemedia,problemsareassumingavoidedthatnottheseonlyareindialsopartstributedofsys-the
persistentvirtualmemory.Simplyignoringremovablemediaordemotingthemto
second-classpersistentstoragemedianegatestheadvantagesofuniformpersistent
simplyvirtualreplacedmemory.byTheadichotomydistinctionofbetweencomputationalfixedandandremovablepersistentmedia.memorywouldbe
mentTheavoidsdecisionthetostoredisadvantagesmoduleofothercapabilitiesmoduleinacapabilityseparate,protectedrepresentations.areaofTaaggedseg-
capabilitieswouldrequireaspecialmemorydesignthatincludestagbitsideally
withmemoryeachdesignwordareofnowmemory.extinct.Howevercomputerarchitecturessupportingsucha
Passwordcapabilitiesareruledoutsincetheirimplementationreliesonacent-
ralrequirecapabilityspecialtable,treatmentwhich(e.g.isainsecurityordertohazardmakeit(cf.persistent)[136]).asThisittablecannotbewouldrepres-also
entedasamodule.Encryptedcapabilitiesarenotconsideredsecureenough,since
thekeymanagementisaproblemthatsofarhasnotbeensolvedfullysatisfactorily
the(thekeytableencryptionarekeyssimilarmaytobethosedisclosedwithaorcentralbroken).capabilityThetable.managementproblemsof

6.4.4SegmentCapabilitiesandPointers
Rdataeferencesstructuresbetweentobesegmentsconstructedarebasedrepresentedonbysegments,pointers.e.g.Plinkedointerslistsallowandarbitraryother
structuresthatcanbedescribedwithgraphs.
2cessedThisignoresdirectlybythethedatakernel,strucfctures.sectionwhich6.2.3.describethegeneralcontentsofacontainerandareac-

162

Chapter6DesignoftheSPEEDOSKernel

Pointerscontainareference(i.e.anoffsetwithinthesamecontainer)toaseg-
mentcapabilitythatdescribesaparticularsegment.Asegmentcapabilitydescribes
aofthesinglesegmentsegmentwithinandtheconsistscontainerofsseveralervesasfields,theasidentifiershownininaFiguresegment6.4.Thecapabilityoffset.
Thereforesegmentcapabilitiesareonlyuniquewithinasinglecontainerandmay
onlyrefertosegmentsinthecontainerinwhichtheyarestored.Itisassumedthat
thesegmentswithinacontainerdonotoverlap.

OffsetContainerinLengthDataofPNumberointersofNumberModCapsofAccessRights

Figure6.4:Representationofasegmentcapability
Thenextthreefieldsspecifythelengthofdata,thenumberofpointersandthe
overallnumberoflengthofmodulethesegmentcapabilitiesandinthetheboundariessegment.betweenEffectivelythethesedifferentdetermineparts.Thethe
pointerandmodulecapabilityareasareneverdirectlyaccessiblebyaprogram.
Onlythekernelmayaccessandmodifytheircontent,topreventforgery.
Theaccessrightsfield3determinestheaccessrightsforeachofthethreeparts
independently.Theaccessrightstosegmentareasarebasicaccessrights,allowing
partsreading,onlywritingreadandandwriteexecutionaccessofrightsthecannormalbedataspecified.tobecontrolled.Fortheother
Pointersmaynotbedirectlymodifiedbyusercode,becausethiswouldallow
ersuserstotorefersettoupsuchsegmentforgedcapabilitiessegmentinthecapabilities.datapartApartofafromsegmentthespecialandusetreatmentpoint-
necessaryreferencestousedenforceintheprogrammingprotectionoflanguages.segments,Theirthesizeispointersnotareunusuallyverylarge,similari.e.to
theThehighersegmentlevelofcapabilitiesprotectionforonlyallcurrentlyintroducesaactivesmallsegmentsstorageareoverhead.heldinsegment
accessregisters.segmentsThereisforafixedwhichanumbersegmentofsuchcapabilityregistersisandloaded.theMemorymodulecodereferencesmayonlyare
expressedSegmentasaregisterspairare<segmentloadedbyregisterthe#,offsetload_pointerinsegment>.instruction,whichloads
thespecifiedtargetasasegmentmemoryregisteroperand.intoThetheeffectivesegmentsegmentcapabilityaccessidentifiedrightsbyarethepotentiallypointer
asreduced,specifiedindependingtheonThreadtheSecuritymaximumRegisteraccess(seerightssectionavailable6.8.3).tothecurrentmodule,
pointerSimilarlyareathereonly.isaThesegmentstore_pointercapabilityisinstruction,notwupdated,hichhoweverbecauseitwritescannottothebe
3Aparticularkernelimplementationcouldalsoincludetheaccessrightsfieldintheleastsignificant
bitsalignedofatopointermultiples.Afew(pbitsowersofofatwo)pointerofthearewordalwayssize.zero,Thisbecauwouldseallowsegmentenforcingcapabilitiesdifferentareusuallaccessy
rightslanguages.perSoreference,farnoexe.g.amplesreferenceshavetobeenconstantfounddatathatreallystructures,requireasthissupportedgranularityinsomeofaccessprogrammingrights.

ModulesComposite6.5

163

changedwiththegenerallyavailableinstructions.Thestore_pointeroperands
arethesourcesegmentregisternumberandthetargetpointerreference.
TheirTheoperationinstructionsisforsubjectloadingtotheandaccessstoringrightspointersdefinedmayinbetheusedsourcebyoranytargetmodule.seg-
ments.BecauseNopointersspecialmaypermissiononlyrefer(i.e.tothesegmentspossessionintheofasamespecialcontainercapability),itisisimpossiblerequired.
tostoreasegmentregisterasapointerinasegmentinadifferentcontainer.
waysCreatingcreatesaanewsegmentsegmentinisthethetaskcontaineroftheholdingthecreate_segmentprivatedataoftheinstruction.currentlyItal-
ation,executingsuchasmodulethebyoffsetsettingintheupacontainersegment,thecapabilitylengthfieldsforit.andTheaccessrequiredrightsofinform-the
newstruction.segmentInareordertocompletelymakethisdefinednewlybythcreatedeoperandssegmenttotheaccessible,thecreate_segmentkernelloadsin-
asegmentregisterwiththenewsegmentcapability.Initiallythesegmentisnot
reachablebyanypointerandthusitiscompletelyprivate.
ules,Thisbecausesegmentthekernelcreationcannotoperationcheckisthenotsuitableplausibilityforofdirecttheusesegmentbyarbitraryallocationmod-and
preventthecreationofoverlappingsegments4.Thustheinstructionalsorequires
presentingakernelcapabilitythatallowstheuseofthisinstruction.
Thepossessionofsuchakernelcapabilitydetermineswhichco-modulesmay
createSegmentsegments.ManagerUsuallyco-module.thecreationEachofco-modulesegmentswhichisdelegatedbelongstotoathesame(trustworthy)com-
positemodulemodulecapabilityandforwhichitsSegmentshouldbeManagerableto.Thiscreatenewcapabilitysegmentscanbemustdistributedpossessasa
partoftheco-modulecreationimplementedbytheCo-moduleManager.

ModulesComposite6.5

Therepresentationofmodulesandtheappropriatemethodinvocationmechanism
arethecoreoftheSPEEDOSkernel,whichfollowsthein-processmodelandimple-
mentsencapsulatemodules.privateThispersistentsectiondatafocusesandonarecompositealsothemodulesfoundation(seeforthechapterprocess5),whichand
.SPEEDOSinmanagementcodeasaTheresepisarateafurthermodule)kindofcannotmodulehaveinprivateSPEEDOSdata,thatcodepersistsmodules,acrosswhichmethod(whencalls,used
similartoprogramsinconventionalsystems.Thisuseandtheprecisecontentand
structureofcodemodulesarediscussedindetaillater.
tionInthecodeforcontextaofparticularcompositeco-module.modulesAttheafirstcodemodulesapproximation,providethetherepresentationimplementa-
ofaco-moduleconsistsofitsprivatedataandthereferencetothecodemoduleim-
a4dataWhichpartcouldthatbeoverlusedapstothecircupointermventtheand/ortheprotectionmoduleofcapabilitcapabilities,ybypart.creatingasegmentwithonly

164

Chapter6DesignoftheSPEEDOSKernel

plementingitsinterface5.ThesimplifiedcontentofthecontainerFforaco-module
6.5.Figureinillustratedis

ModCap

Co-ModuleRCodeootPointerModCap

ModuleCode

CContainer

dataCContainersegmentsFContainerFigure6.5:Simplifieddatastructuresdescribingasingleco-module

Thecompleteprivatedataofanentirecompositemoduleisstoredinasingle
container.Analternativerepresentationthatwouldallowarbitraryplacementof
theprivatedataofdifferentco-modulesindifferentcontainerswasalsoevaluated,
butwasnotselectedbecauseofitsgreatercomplexity.Thedifferencetousinga
numberofseparatecompositemoduleswastoosmalltojustifytheeffort.
theArespectiveco-moduleisCo-modulecreatedTbyablesettingentry.upThistheisrootthepointerresponsibilityandtheofcodethecapabilityCo-modulein
Manager,whichreturnsamodulecapabilityforthenewlycreatedco-module.
EachentryintheCo-moduleTableadditionallycontainsamodulecapabilityfor
6aindividualqualifierlistco-module.moduleTheinuseorderoftothisfieldsupportisdifferentdiscussedinqualifyingdetaillater.modulesTheforcompleteeach
informationheldintheCo-moduleTableisillustratedinFigure6.6.

ableTCo-Module0RootPointerCodeModCapQualifierListModCap
1RootPointerCodeModCapQualifierListModCap
2.RootP.ointerCode.ModCapQualifierList.ModCap
........

Figure6.6:Co-moduleTabledescribingthecontentofacompositemodule
5Sharingtheimplementationcodefordifferentco-modulesisamatterofusingthesamecode
modulecapability.Codemodulesareassumedtobereentrant.
6thatThetherequalifierisnolistqualifiemodulerlistcapabilitymodulefieldassociatedmaywithcontainaanparticularinvalidCo-mmoduleoduleTcapabilityable,entrywhich.indicates

ManagementInterruptandProcess6.6

165

Thedifferentco-modulesstoretheirprivatedatainasinglecontainer,thusthe
handlingoftherootsegmentdetermineswhetheraco-modulehasitsownprivate
dataorhasaccesstotheprivatedataofanotherco-module(whichwasmentioned
inchapter5inthecontextofdebuggingsupport).
Thisdatastructuredescribingthestructureofacompositemoduleissimple
enoughfordirectuseinthekernel,providedthattheco-modulenumbersaresmall
integers.Thisallowsastraightforwardarrayrepresentation.Thekernelonlyreads
theCo-moduleTableandnevermodifiesitscontent.Thecreationofcontainers
andconsequentlytheinitialsetupoftheCo-moduleTableisthetaskofuser-level
modulesandwillbedescribedinchapter7.

ManagementInterruptandProcess6.6ProcessesaretheabstractionofactivityinSPEEDOS.Thekernelprovidesbasic
supportforprocesses,buttheorganisationofprocessesisalmostentirelydelegated
modules.user-leveltoThereisonlyasingleprocessconceptinSPEEDOSandthekerneldoesnothave
aspecialkernelprocessnotionrepresentingactivitieswithinthekernel.Allker-
nelinstructionsareexecutedin-process.Howeversomeprocessesperformsystem
duties,whichforvariousreasonscannotbeimplementedinthecontextofthepro-
users.particularrepresentingcessesForeachprocessor,thekernelmaintainsasetofregisters(bothprocessorre-
gistersandvirtualregistersimplementedbythekernel)thatrepresentsthestateof
thecurrentlyexecutingprocess.Thisprocessstateincludesthecurrentlyaddress-
ablepartofthevirtualmemory,becausethereisasingle,uniformpersistentvirtual
memoryinwhichallinformationaboutprocessesandmodulesisstored.
ActuallyinSPEEDOSasingleprocesssupportsseveralindependentthreadsof
execution(fromnowonreferredtoasthreads).Theentirestateofaprocess(in-
cludingallthreadsdefinedwithinit)isstoredinasinglecontainer.Processesare
intendedtorepresentseparateuseractivitiesandthreadsareintendedtoimple-
mentparallelactivitieswithinanapplication.
Allthreadswithinaprocessareassociatedwithasingleowner,sincetheowner
processesinformationisand/orassociatedthreadsiswithaultimatelycontainersubject.toWhetherthetodecisionsmakeofusetheofoneuser,orthemoreap-
plicationdesignerandtheOSdesigner.

ThreadsApplication6.6.1Thekernelsupportsapplicationthreadswhichcanbe(andtypicallyare)persistent.
Frommodelisthekernel’ssupportedbyviewpointthekernel’stheseoperateinter-moduleaccordingcallto(IMC)theandin-processinter-modulemodel.returnThis
instruction(IMR),whichtransformtheprotectiondomainofaprocessfromone
moduleenvironmenttoanotherwithoutaprocessswitch.

166

Chapter6DesignoftheSPEEDOSKernel

Creationandgeneraladministrationofthethreadswithinaprocess,including
theallocationofalinkagestackforeachthread,isorganisedbytheThreadManager
(seesection6.3above),whichisanormalco-module.
cessedTheThreaddirectlybyManagerthekernel.constructsTheasegmentsThreadTablereachable(seeviaFiguretheroot6.7),pointerswhichinisac-the
theThreadcurrentTableregistercomprisecontentsthe7globalandthestateofaddressingeachthread,environmentincludingofthethelinkagecurrentstack,mod-
ule.Theschedulingparametersarenotconsideredpartofthethreadstate.
ProcessointerPootR0TThreadable1RootP.ointer
.2.......

stacksegmentsPContainerFigure6.7:ThreadTableandthreadrepresentationwithinaprocess
Allprinciplethreadsdonotwithinshareatheirprocessareaddressingcompletelyenvironment8,independenti.e.theyofmayeachexecuteotheranddiffer-in
enteachothermodules.,thereSincearethegenerallydifferentnothreadsreferencesstoredbetweeninathecontainerrepresentationsareisolatedofdiffer-from
entthreads,avoidingsharingproblemswithstacksegments.
staticTheaspectsco-moduleofthecapabilitythreadsforwithintheaThreadprocess.TheManagerthreadcanbecorrespondingusedtotomanageanewlythe
addedentryintheThreadTabledoesnotimmediatelystartexecution,unlessthe
ThreadEverythreadManageralsopossessesmakesathegloballythreaduniqueknownidentifiertothe,whichThreadconsistsSchedulerof.theunique
containernumberofitsprocessandathreadnumberwithinthecontainer.When
the(whichkernelisparthandlesoftheancurrentIMCitthreadcanusestate)thetothreadfindtheidentifierlinkageofstacktheofthecurrentthread.thread
7whileThethecontentthreadofistheexecutingstateinarepresentationmodule,butforaisupdcurrentlyatedwhenactivethethreadschedulermaynotswitchesbekepttoaup-to-datedifferent
8threadorwhenamoduleisinvoked.
ilarityThreadswithintheSPEEDOSthreadarenotionmoreinconvlikeentionalprocessesinoperatingconventionalsystems,systemswhichandoftenhaverefertoonlylittlelightweighsim-t
processeswhichsharetheiraddressingenvironment.

ManagementInterruptandProcess6.6

167

6.6.2StackOrganisationandParameterPassing
Thelinkagestackisstoredinasinglesegment,whichconsistsoftheinvocation
records.Thesecontainthestateofthemoduleexecutioninthecurrentthread
foreitherthecurrentmodule(incaseofthetop-of-stackrecord)orforprevious
modulesinthecallchain.Therecordsstoretheregistercontentsandothercall-
relatedGenerallyinformationparameterssuchasandpointersreturntovaluestheareparameterpassedinandregisters,returnvaluewhicharesegments.made
values).accessibleIntotheprinciplecalledtheremoduleisa(forseparateparameters)setoforregisterstheforcallingeachmodulebasic(fordatareturntype,
i.e.processornormaldata,registers,poipointersntersandaremodulepassedincapabilities.segmentregistersNormalanddataismodulepassedincapabilit-the
isiesaredefinedpassedbyainparticularmodulekernelcapabilityregisters.implementationTheandnumberitisofeachexplicitlykindofpermittedregistersby
thereferenceSPEEDOSmodulekernelcapabilitiesdesigntowithomitthememorymoduleoperands.capabilityregisterscompletelyand
ersSinceand/orthereturnnumberofvalues,itregistersisisalsoinsomepossiblecasestonotpassexactlysufficienttoonepasssegmenttheparamet-register
tothecalledmoduleand/ortothecallingmodule.Thissegmentmustbestored
inacontainercontainerwiththewhichthreadissharedstack.Forbetweenthethecreationcallingofandsegmentsthecalledinthismodule,containeri.e.thethe
responsibleSegmentManagerco-modulemustbeused.Itwouldbetoorestrictive
toferentrequireforeachthatallprocessmodulesandwouldpossessaeffectivelysuitableneedmoduletobepassedcapabilityin,everybecauseitparameterisdif-
list.alsoThiscontainsistooasinglecomplicatedmoduleincapabilitypractice.(whichThusitisisnotdefinedshownthatintheFigureThread6.7Tabove)able
fortheSegmentManagerresponsiblefortheprocess,whichallowssegmentstobe
allocatedbythecurrentmoduleintheprocesscontainer.
ThelinkagestackrepresentingthemethodcallchainisshowninFigure6.8,
includingparameterandreturnvaluesegments.
Thread

invocationrecordinvocationrecordstacklinkagesegmentPContainer

valuereturnsegment

parametersegment

Figure6.8:Linkagestackwithparameterandreturnvaluesegments

168

Chapter6DesignoftheSPEEDOSKernel

Thediagramillustratesthesituationwhenthecurrentmodule(representedby
thetopmostinvocationrecord)isabouttoreturnareferencetoareturnvalue
whichsegment.isTheindicatedreturnbyvaluethegreysegmentarrow.thenEffectivelybecomesthisaccessiblemeansbythatthethecallinginter-modulemodule,
returnoperationrestoresthecontentofallsegmentregistersexceptone.
metersSegmentsandreturnallocatedvalues,inatheyprocessmayalsocontainerbeusedmayfornotonlystoringbelocalusedtovariables.passpara-The
anismcompilerwithincanausemodule,suchforsegmentswhichtonoorganisespecificthekernelinternalsupportmethodexists.invocationmech-
ItdepositedisdescribedSegmentlaterinManagerthecontextcapabilityofthemaybeusedinter-modulewithoutcalldisclosingmechanismit.howthe
WithineachcontainerthereisonlyasingleSegmentManagerco-module,i.e.
theregardlessvirtualwhethermemorythesegmentsmemoryisbelongingusedtotoonerepresentcontaineramoduleareora“centrally”process.managed,

6.6.3ControllingExecutionofIndividualThreads
Whenaprocessiscreated,therearetwoentriesaddedtoitsCo-moduleTable.
TheThreadManager(asdescribedinsection6.6.1)istheapplicationco-module
trolresponsibleManagerfor(TCM),updatingwhichtheisthreadresponsibletable.forTheothercontrollingtheco-moduledynamicistheaspectsThreadofCon-the
threadswithinaprocess,i.e.theirexecutionandschedulingparameters,incooper-
isaationtrustedwiththeco-moduleThreadandSchedulerpossesses,whichaismoduledescribedcapabilityinthefornexttheThreadsection.TheSchedulerTCM.
TheThreadManagerissuesathreadcapabilitywhenanewthreadiscreated.A
threadcapabilityisaspecialtypeofamodulecapability(withthetypethreadand
thethreadnumberstoredintheindexfield).
TheTCMusesthemethodsimplementedbytheThreadSchedulertoprovide
canoperationsbetailoredwhichtowardscontrolthetheneedsthreadsofthewithinaapplicationssingleprocessexecutedonly.withinThusatheprocessTCM
andcanimplementapplication-specificpolicies,e.g.theTCMcanenforcethatonly
aroutines.singleThethreadkernelwithindoesanotprocessdirectlyisuseactive,thewhichTCM,canbutbeonlyusedthetoThreadimplementSchedulerco-.
Ifathreadcapabilityisspecifiedasthetargetofaninter-modulecallthenthe
kernelinvokestheTCMassociatedwiththeprocess.Thekerneladditionallypasses
themethod.threadThusnumberathread(whichiscapabilitypartofgivesthecontrolthreadoveracapability)singletothethreadinvokedonlyandTCMis
suitablefordistributiontoothermodulesandthreadswhichshouldbeableto
withincontrolantheapplicationexecutionofsuchanotherasaddingthread,ore.g.inremovingorderatoparticularmanagethreadparallelfromactivitiesthe
ThreadScheduler.DirectaccesstotheThreadSchedulerislimitedtotrustedco-
ifmodules,applicationswhichwouldavoidsmayroutinelyprotectionpossessaandcapabilityavailabilityfortheproblemsThreadthatSchedulerwould.arise

Process6.6ManagementInterruptand

169

threads.TheTCMandCooperationtheThreadbetweenSchedulerdifferentprimarilythreadscontrolrequirestheexecutionsynchronisation,ofindividualwhich
canbesynchronisationimplementedconceptsbyarecoordinateddiscusseduseinofthemoredetailschedulerinsectionoperations.6.6.7.Thenecessary

SchedulingThread6.6.4Theschedulingofthreadsistheresponsibilityofacentralpolicymoduleofthe
operatingsystem,theThreadScheduler.Eachnodeinalooselycoupleddistrib-
utedprocessorsSPEEDOSwithinsystemanode.hasaItisseparatepossibleThreadtoimplementScheduler,awhichscheduleristhatresponsiblecooperatesforall
withtheschedulersonothernodes.Eachschedulercanhavedifferentscheduling
activepolicies.threadThe(whichkerneliscanofawarecourseofonlybetheoneidlethreadthread).perprocessor,i.e.thecurrently
Thesinglethreadperprocessorsupportedbythekernelisanecessary,butfora
aboutusableallOSnotrunnableasufficientthreadsbasis.andThetheirThreadschedulingSchedulerparameters.fillsthisItgap,determinessinceitknowswhen
athreadswitchshouldoccurandinstigatesthisbyusingthekernelinstruction
thread_switch,specifyingauniquethreadidentifier.
stateUsingofathethread,latterthewhichiskernelheldcaninthedirectlycontaineraccessoftheitsdataThreadstructureManager.describingThekernelthe
effectsthethreadswitchbystoringthestateofthecurrentthreadinthedata
thread.structureThedefinednewbythreaditsthreadimmediatelyidentifierbeginsandexecution.thenInloadingathemulti-processorstateofthesystemnew
thethreadswitchisalwayseffectedonthecurrentprocessor.
Thetargetthreadidentifierissimplyanunprotecteduniquenumericidentifier.
Theallowstothread_switchswitchthreads.instructionNormalrequiresmodulesthegenerallypossessiondoofnotakernelpossessthecapabilityrequiredthat
kernelcapabilityandmaythusnotinterferewiththeschedulingpolicybyswitching
threadsdirectlytodeterminesanotherthread.whichThemodulesdistributionmaycontrolofkernelthescheduling.capabilitiesItisallowingeventopossibleswitch
toimplementhierarchicalscheduling,ifdesired.
Fortechnicalreasonsthereisanadditionalreturn_thread_switchinstruc-
tionthreadthatswitchperformstothethespecifiedcombinationthread.ofThisanisusedinter-moduleinthereturnschedulertoinstructionoptimiseandthea
Itsuseofmainpurposethread_switchistosimplifyasthethelasttaskofinstructionmigratingbeforeaprocessreturningtofromanotherthenode.method.
ThemethodsoftheThreadSchedulermustbeexecutedindivisibly,otherwisethe
schedulerimplementationbecomesverycomplicatedanddeadlock-prone.Thead-
optedschedulersolutionexecutes.intheThisSPEEDOSensureskernelthatiseventodisableinterruptinterruptshandlerswhilemayausemethodtheofsched-the
ulersynchronisingwithoutfurtherconcurrentprecautions.accessesonTheacentralmulti-processorschedulersystemmoduleasisrequired,responsiblee.g.forby

170

Chapter6DesignoftheSPEEDOSKernel

usingthebasicsynchronisationinstructionsprovidedbytheprocessorarchitecture.
WhenathreadinvokestheThreadScheduleritisrecognisedbyitsuniqueiden-
tifierandfortheschedulermoduleinterruptsremaindisabledwhilethemethodof
theschedulermoduleisexecuted.Whentheschedulermodulereturnstoitsclient
module,interruptprocessingisre-enabledonthecurrentprocessor.
ApartfromthisspecialmechanismfortheThreadSchedulertherearenomeans
todisableinterrupthandlinginSPEEDOS.Blockinginterrupts(apopularad-hoc
solutionforkernelsthatdonotcareaboutschedulingprecision)interfereswith
theschedulingpolicyandisathreattotheavailabilityofthesystem.Thebetter
solutionistodefinetheschedulingpolicyandtheschedulingparameterscorrectly,
e.g.bymarkingtherespectivethreadsasnotrunnablebytheThreadScheduler.

InstructionsernelKImplementing6.6.5Kernelinstructionsareexecutedasatomicoperations.Thekerneldoesnotblock
theprocessinthemiddleofsuchaninstruction,but(ifnecessary)arrangesthat
theallyprocessre-tried9iswhenblockedthebeforecauseofthetheinstruction.blockingisThusremoved.theTheinstructionpersistentisautomatic-virtual
andmemoryinternalneverkernelcontainsimplementationinformationdetailsaboutaarenotpartiallyinvisibleexecutedtomodules.kernelinstruction
Thisproblemsallowsofsomethekernelothertobepersistentreplacedoperating(duringasystems,systemwhichshutdown)exposeandtheiravoidsinternalthe
structureaddressesofandstateinternalkernelindirectlyfunctions.throughIttheisthuslinkagepossibleinformationinSPEEDOSthate.g.tocontainsreplace
thementationkernelwitherror.aRversioneplacingwiththekernelimprovedisanperformanceoperationorthatinonorderprincipletofixancannotimple-be
performedonarunningSPEEDOSsystem.
Theatomicityofkernelinstructionshasanimportantconsequence,namelythat
onlyasinglekernelstackperprocessorisrequiredinSPEEDOS.Thekernelstack
neverrepresentsblockstheinthetemporarymiddleofstateanrequiredinstruction,byathiskernelstackmayinstruction.bereusedSinceforthethekernelnext
maykernelbeusedinstruction,forthewithoutinterruptlimitinghandlingparallelisminimplementationanyway.inThethesamekernelkernel(seestacknext
Rsection),educingsincetheinterruptsnumberofareinkernelprinciplestackswashandledalsobetweenattemptedkernelintheinstructionscontextofonlymi-.
beacrokernelsperformance(i.e.theout-ofbottleneck-processandamodewastel),ofbecausemainkernelmemory10stacks.Theweresolutionidentifiedthereto
wastointroduce“continuationobjects”[66],whicharemuchmorecomplicated.
Thelowsthedesignofin-processthemodelSPEEDOSandkernelclearlyallowsseparatesasimple,betweenefficientactiveandsolution,passivesinceitobjects.fol-
9Theprogramcounterandthefurtherthreadstateareonlymodifiedoninstructioncompletion.
a10Inaseparatemicrokernelkernelstack,mostbecausethreadstheyareintheinvokedablockedkernelstate.Aoperationllthreadsthate.g.blockedwaitingthemforawhileinmessagekerneluse.

Process6.6ManagementInterruptand

171

HandlingInterrupt6.6.6Foreachasynchronous(i.e.device-related)interruptsourcethekernelmaintains
anon-persistentlistofinterrupthandlingthreads.Dependingonthehardware
thekerneldistinguishesbetweeninterruptssignalledbyindividualdevicesorby
devices.ofgroupsThereisaprotectedkernelinstructionwait_interruptwhichaddsthethread
invokingtheinstructiontoaparticularlistofinterrupthandlingthreads(indicated
byanoperand).Thisinstructionsuspendsthecurrentthreadbyinvokingamethod
oftheThreadScheduler.Thekernelineffectmanagesapoolofinterrupthandling
threadsforeachimmediatelydistinguishableinterruptsource.Itisthedecision
ofthesystemdesignertodecidehowmanythreadsarerequiredforaparticular
interruptsource.Thesimplestcase,eliminatingtheneedforsynchronisation,is
tohaveonlyasinglethreadforinterruptsfromaparticularsource.Handling
interruptssequentiallycanhoweverlimittheperformanceofaSPEEDOSsystem.
Wheneveraninterruptoccurs,thekernelremovesonethreadidentifierfrom
thelistcorrespondingwiththeinterruptsourceandresumestheexecutionofthis
threadbyinvokingamethodoftheThreadScheduler.Itisnowthetaskofthe
resumedthreadtohandletheinterrupt.Notethattheinterrupthandlingthread
isonlyresumed,butnotimmediatelyassignedaprocessor.TheThreadScheduler
stillhascompletecontrolovertheschedulingpolicy.Thisisimportante.g.for
real-timesystemswhichcannottoleratedeviationsfromtheschedule.
Afterthethreadhashandledtheinterrupt,itusuallyaddsitselfagaintothelist
ofinterrupthandlingthreadsbyinvokingthewait_interruptinstruction.
Asaconsequenceofthisdesign,asynchronousinterruptsarehandledfollowing
theout-of-processmodel,similartothedescriptionofhardwarekernelprocesses
in[237].HoweverthehardwarekernelprocessesareinSPEEDOSnormal,persist-
entthreadsjustlikeanyapplicationthread.
Thewait_interruptinstructionisprotectedbyakernelcapability.Itwould
beathreattotheavailabilityofthesystemifnormaluserthreadscouldregister
themselvesasinterrupthandlingthreads,becausethiswouldinterferewiththe
interrupthandlingthreads,whichareusuallyrelatedtodevicedrivers.
Synchronousinterrupts(sometimesalsocalledprogram-relatedinterruptsor
traps)arehandleddifferently.Theyarecausedbythecurrentlyrunningprogram
(e.g.divisionbyzeroorpagefault)andarehandledinSPEEDOSprimarilythrough
aforcedmethodcalltoaco-moduleofthecurrentmodule,i.e.strictlyfollowingthe
in-processmodel.Thekernelperformsthecompleteinterruptanalysisinthiscase
beforeinvokingtheresponsiblehandlermethod.Formostsynchronousinterrupts
thehandlerisamethodoftheTrapManagerco-moduleofthecurrentmodule.
Handlingpagefaultshasalreadybeenmentionedinsection6.4.2andworks
inprincipleinthesameway,exceptthatthefunctionalityisdistributedbetween
thecentralContainerDirectorymoduleandthePageTableManagerco-module.
Howeverintheimplementationofvirtualmemoryitispossiblethatapagefault
occursinthestackarea.Inthiscaseitisingeneralimpossibletohandlethefault

172

Chapter6DesignoftheSPEEDOSKernel

usingfaults.theForsamethislinkagepurposethestack,askernelusingalsothesupportscurrentstackhandlingmayofcausepagefaultsfurtherinpagethe
contextofaproxythread,whichispartofadifferentprocess.
ThemechanismresemblesasynchronousRPCinvocation,i.e.theoriginalthread
issuspendedandthemethodcallisperformedinthecontextofaproxythread.
ARPCfteristhepageimplementedfaultbywasthehandled,kernel,thewhichoriginalinvokesthreadmethodsisofresumed.theThisThreadsynchronousScheduler
moduleinordertotemporarilyreplacethethreadcausingthefaultwithasubsti-
tute(usingtheschedulingparametersofthefaultingthread).Forthispurposethe
thatkernelthemanagesoverallastylepoolofofpageproxyfaultthreadshandlingjustasfollowsfortheasynchronousin-processmodelinterrupts,asexceptclosely
aspossible.Thehandlerisstillinvokedthroughaforcedmethodcall,although
fortechnicalreasonsinthecontextofanotherthread.Theproxythreadsregister
themselvesbyusingthewait_interruptinstruction,specifyingaspecialinter-
ruptsource(e.g.-1)whichstandsforsynchronousinterrupthandlingthreads.
Inordertocontroltheexecutionofthreads,thekernelusesanumberofmeth-
odsoftheThreadScheduler.Thekernelimplementssynchronisationinstructions
basedontheThreadScheduler’smethodsandusesthesesynchronisationprimit-
ivestocoordinatethethreadexecution,insofarasthekernelneedstoinfluenceit
inreactiontointerruptsandinordertoimplementotherkernelinstructions.
Generallytheschedulermoduleislockedintothemainmemoryandcannotbe
accessedfromaremotenodeusingdistributedsharedmemory.Henceinterrupt
handling(synchronousandasynchronous)cannotinterferewiththescheduling.

Synchronisation6.6.7Thisthemecanbeconsideredintwoparts.Thefirstistheissueofsynchronisingthe
kernelinstructionswithotheractivity.Suchactivityincludesthesynchronisationof
thekernelavailableinstructionsfacilitiesofconcurrentlytheprocessoractiveinahardwaremulti-processormustbeusedsystem.inForderortothismaintainpurpose
anconsistencyinternal,issuee.g.toforaimplementparticularatomickernelmoduleimplementation.capabilityupdates.Howeverthisis
Themodulessecondwhichandupdatemoreorimportantaccesstheissueispersistenthowthedatakernelstructurescaninasynchronisecontainerwiththatco-
areaccesseddirectlybythekernel(seesection6.2.3).Forthispurposetheker-
nelandwhichprovidesitalsoprimitivemakesreader/writeravailabletosemaphoreco-modulesinoperationstheformwhichofitkernelusesinstructionsinternally
(sem_read_p,sem_read_v,sem_write_pandsem_write_vwiththeusual
waitssemantics,inthee.g.ThreadasdescribedSchedulerin,if[135]).necessaryThe.threadinwhichthekernelisactivethen
Theimplementationofthesesemaphoreinstructionsinthekernelusesmeth-
odsincludingofthetheThreadassociatedSchedulerwaitingwhichlistcarrymanagement.outthecontrolHoweveroverthekernelthreadinvokesexecution,the

ModulesLibraryandCode6.7

173

(cf.ThreadtheSchedulersemaphoreonlyforimplementationsemaphoredescribedoperationsin[138],thatblockbutorwiththeunblockrolesaofthreadthe
swapped).codeuser-levelandkernelAllotherstateupdatesareimplementeddirectlybythekernel.Effectivelythe
datedsemaphorebythekernelrepresentationandtheissplitwaitinginlisttwowhichparts,isthemaintainedcountersbywhichtheareThreaddirectlySched-up-
uler.identifierThe,whichrelationshipconsistsofbetweenthefullbothvirtualisestablishedmemoryaddressthrough(theauniquecontainersemaphorenumber
andtheoffsetwithinthecontainer)ofthesemaphore.TheThreadScheduleronly
needstostoreinformationaboutnon-emptywaitinglists.
Ofcoursethekernelandtheco-modulesaccessingthesamedatastructureshave
totemisadhereattorisk.theThesameThreadsynchronisationSchedulerstillprotocol,hascontrolotherwiseoverthethesecurityschedulingofthepolicysys-,
becausethekerneldoesnotswitchthreadsdirectly.
Thekernel-providedinstructionsforsynchronisationmaybeusedbyanymod-
ule,buttheirusebynormalapplicationsisnotenforced.Semaphoresandother
operationsynchronisationwiththeschemesThreadmaybeScheduler.implementedThuseachcompletelymodulemayatthefreelyuserselectlevel,theinap-co-
propriatesynchronisationimplementation.Theimplementationofsuchsynchron-
isationprimitiveswillbegenerallypartofalibrary,whichpossessesacapabilityfor
agethetheThreadwaitingSchedulerlistsince.Theitcanlibrarybe(ifgivenaccessimplementedtotheasalow-levelfilelibrary)schedulercanevenoperationsman-
thatthreadsuspendidentifieror.resumeThisdistributesindividualthethreads,waitinglistidentifiedbymanagementtheirtounprotectedtheapplicationsnumeric
whichimplementtheirownsynchronisationmechanisms.

ModulesLibraryandCode6.7

Theinformationhidingprincipledeterminesthestructureandorganisationofcode
whichmodules.Theunderstandspersistenttheprivatedatadatastructurestructuresofafileofthemodulefilemodule.referstoTheacodecodemodulemodule
offersasemanticinterfacewhichenforcesinformationhiding.Inadditioncode
gramsmodulesorcansubroutinebedevelopedlibraries).whichCodehavemodulesnoarepersistentheldindataseparatestructurescontainers.(e.g.asTheypro-
beginstants,theircapabilitieslifeasfileetc.),modulesi.e.theindatawhichthegeneratedpersistentbyadatacompileriscodeor(andlinker.relatedFilecon-and
codeThemodulesinterfaceareofacodedistinguishedmodulebythe(itstypesemanticfieldinainterface)moduleconsistscapabilityof.anumber
ofmethodswhichcanbeinvokedeitherdirectly(inthecaseofa“program”)or
indirectlyasthesemanticmethodsofafilemodule.Thekernelcanlocatethese
interfacesegment.Suchmethodsa(insegmentordertocontainsexecuteinitsanpointerIMC)sectionfromanthearrayEntryofPointpointersListto(EPL)the
individualcodesegments(severalpointersmayrefertothesamecodesegment)

174

Chapter6DesignoftheSPEEDOSKernel

andinitsdatasectionanarrayofintegeroffsetsindicatingtheoffsetwithinthe
segmentwherethecodeforthemethodbegins.Thesearraysareindexedbythe
Itmethodisdesirablenumber,towhichsupportispassedcodeasreuseabetweenparametertoanimplementationsinter-moduleofcall.differenttypes
(e.g.toreusetheimplementationofadouble-endedqueueintheimplementation
aofasinglestack).containerThis,issinceonlypointerspossibleifcannotseveralrefercodetomodulessegmentscaninbeotherdefinedcontainers.within
Anotheruseofsuchgroupingofcodemodulesisthesupportforseveralimple-
mentationsofthesametype(e.g.withdifferentperformancecharacteristics)in
ofoneadefaultcontainer.Inthisimplementation.caseitAmaybeside-effectdesirableofstoringtosupportseveralancodeautomaticmodulesinselectionone
containerisimprovedstorageefficiency.
Thegeneralmechanismtodistinguishbetweenseveralimplementationsofone
thecodecontainermoduleisnumberthroughtheformsindexthefieldmoduleinaidentifiermodule.Thecapability,relationshipwhichtogetherbetweenwitha
compositecodemoduleandacodemoduleisanalogoustotherelationshipbetween
awhichcompositecontainsamodulepointerandatotheco-module.EntryPTheointList,indexaselectsmoduleanentrycapabilityoftheforaCodeTqualifierable,
listmodulemoduleoraandcodeaflaglibrary.thatTheindicateslattertwowhetherfieldsthisareentrydescribeddescribeslateraninactualdetail.codeThe
contentofacodemoduleisshowninFigure6.9.
ModuleCodeCode0EntryPointListPointerQualifierListModCapLibraryFlag
Table1EntryPointListPointerQualifierListModCapLibraryFlag
2..EntryPoint..ListPointerQualifier..ListModCapLibrary..Flag
....

CContainer

Figure6.9:CodeTablerepresentationwithinacodemodule
theTheentrydiagrampointlistsshowsisacodeunchangedmoduleandwitheachthreeentryentrypointpointcontainslists.aThepointerformattotheof
actualcodesegment(theblackarrow)andthestartingaddress(i.e.therelative
offset,drawnasagreyarrow)ofthemethodinthatsegment.Thisallowsarbitrary

ModulesLibraryandCode6.7

175

structurestobeusedtorepresentthecode,rangingfromasinglesegment(asused
inCodeTableentry2)tousingmultiplesegments(asinCodeTableentry0and1).
Sharingofcodesegmentsbetweendifferentinterfacesispossible.Thecompileror
linkerisresponsibleforcreatingthesestructures,asmentionedinsection6.3.
TheCodeTablemustnotbeconfusedwiththeCo-moduleTableofacodemod-
ule,asthesehaveverydifferentpurposes.Thegeneralstructureandtheindirection
issimilar,buttheinformationrepresentedinbothtablesisfundamentallydifferent.
Codesegmentscanthemselvescontainpointerstofurthercodesegments(repres-
entinginternalroutines)andtodatasegments(e.g.forconstants).Suchsegments
canalsocontainmodulecapabilities.Thisinternalstructureisnotdeterminedby
thekernel,sinceitisnotresponsibleforinvokinginternalroutines11.
TheCodeTableisnotaconstantdatastructure.Itmaybechangedatrun-
time,addingnewcodemodulesanddeletingnolongerneededcodemodules.
Specialcaremustbetakennottobreakexistingpersistentmodulesbyreplacing
theimplementationtheyuse(e.g.byoverwritingthecodesegmentswithanew
implementation).TheCodeManagermayreplacetheEntryPointListpointerinan
entrysafelywithapointertoanewimplementation,providedthatthenewversion
usesexactlythesameinternaldatarepresentation.Currentlyactivemodulesusing
theoldimplementationcontinuetoworkasexpected,astheinter-modulecall
storesareferencetotheEPLinthelinkage.
Theselectionofadefaultimplementationincaseswheretheuserdoeswantto
specifywhichofseveralimplementationsofthesametypetouse(e.g.tousethe
latestcorrectedversionofacodemodule)isnotpossibleinafullyautomaticway.
Inthecontextofafilemoduleitmustbeensuredthatalwaysthesameimplement-
ationisused,i.e.theselectionofaparticularcodemodulemustbeperformedat
filecreationtime.Howanimplementationisselectedislefttouser-levelcode,e.g.
aspartofthecompilerrun-timelibraries.Thecodemodulecapabilitydetermines
used.isimplementationwhichAnormalcodemoduleiscompiledinsuchawaythatitcandirectlyaccessthe
segmentsofitsassociatedfilestructure.TheIMCinstructionisresponsibleforset-
tinguptheaddressingenvironmentinsuchawaythatthefilesegmentsassociated
withthecurrentfilemodulecanbeloadedintosegmentregisters.
Alibraryisorganisedinasimilarwaytoanormalfileorcodemodulewith
oneimportantdifference.Alibrarymayaddressasegmentofitsclientmodule
inadditiontothecodesegmentsand(ifapplicable)privatedatasegmentsofthe
librarymodule.Inthecaseofacodelibrarythismeansthatthecodehasdirect
accesstothepassedsegment,whichisusuallypartoftheclient’sfilecontainer.
Similarlyforafilelibrarythepassedsegmentisaddressableinadditiontotheroot
.librarytheofsegmentLibrariescanonlybeinvokedbyakernelinstructionknownaslibrarycall(LC).
11LocalThecalllinkagelinkagestackismadetheavailableresponsibilitytotheofthekernelbycompilera,Threadwhichcan,Managerbutisneedusednot,onlyforuseIMCtheproclinkage.ess
containerforthispurpose(seesection6.6.2).

176

Chapter6DesignoftheSPEEDOSKernel

ALCisrestrictedtotargetswhichhavethelibraryflagsetintheCodeTableentry
correspondingtotheinvokedco-module.Codelibrariesandfilelibrariesaredis-
tinguishedbythecontentofthetypefieldofthecapabilitypresentedtotheLC.
Thetechniqueusedtomakethepassedsegmentoftheclientmoduleaccessible
isthatasegmentregisterispre-loadedwiththesegmentcapability.Ifthetarget
ofanLCisafilemodulecapability,thenboththepassedsegmentoftheclientfile
moduleandtherootsegmentofthefilelibraryaremadeaccessible.Inthiscase
thepassedsegmentmustbestoredeitherinthecontainerofthecurrentthreador
inthesamecontainerastheprivatedataofthefilelibrary,otherwisetheLCfails.
OnewayofviewingthedifferencebetweentheIMCandaLCisthattheformer
establishesatightlyboundrelationshipbetweencodeandfiledatabymeansof
entriesintheco-moduletable,whilethelattercanbeboundtoanypersistent
datasegmentsasparameters.Thereasonwhybotharesupportedisthatthetight
bindingisappropriatewithaninformation-hidingfile,whilelibrariesallowtheuse
oflibraryroutinesinthecontextofaclientmodule.
Librariessupportefficientimplementationofsmallobjects(e.g.strings,stacks,
trees,object-orientedobjectsetc.)eveninanOScontext,whereplacinginforma-
tioninseparatemoduleswouldbeprohibitivelyexpensiveandunnecessaryfrom
theviewpointofprotection.Iftheinformation-hidingprinciplewerestrictlyfol-
lowedwithoutlibraries,suchstandardcodemodulescouldnotbesharedbuttheir
codewouldhavetoberepeatedineachmodule.

MechanismsProtection6.8

Thecussedkeyinsectionprotection6.8.1.featureSectionofSPEEDOS6.8.2isdescribesthehowmodulebracketcapability.methodsTheseareareinteg-dis-
ratedtectionintofeature,thekerneltheThreaddesign.SecurityFinallyRsectionegister.6.8.3describesanotherimportantpro-

CapabilitiesModule6.8.1ThecompletecontentofamodulecapabilityinSPEEDOSisshowninFigure6.10.
theTheaccessbasicfieldsrights.fromthegeneralcapabilitydefinitionarethemoduleidentifierand

ModuleIdentifierTypeMetarightsEnvironmentConfinementRightsandAccessRights

Index#Container

Figure6.10:Representationofamodulecapability

MechanismsProtection6.8

177

Themoduleidentifier(whichisbothgloballyuniqueanduniqueovertime)has
alreadybeendiscussedindetail.Themainpartofthemoduleidentifieristhe
containernumber,whichmeansthatacontainernumbermustneverbereused.
Reusingamoduleidentifierforwhichmodulecapabilitiesstillexistwouldmake
themvalidagain,givingtheholdersofthesecapabilitiesaccesstoamodulewhich
shouldnotbeaccessibletothem.Theindexfieldisonlyuniquewithinacontainer
andforaparticularmodulecapabilitytype.
Thenextthreefieldsarenotpartofthegeneralcapabilitymodel,butrepres-
entfurtherstructuringandprotectionpossibilities.Thetypefielddistinguishes
betweendifferentkindsofmodulecapabilitiesforfilemodules,codemodulesor
threads.Therearealsoothertypesofcapabilitiesforspecialpurposessuchas
kernelcapabilities,whicharegenerallyusedonlyinthecontextofOSmodules.
Thesamecontainermaybeusedinmodulecapabilitieswithdifferenttype.The
interpretationofthecontainercontentthusdependsonthetypeofthemodulecap-
abilitypresentedtothekernel.Capabilitieswithdifferenttypesmayexistconcur-
rentlyforasinglecontainer,i.e.itispossibletocreatesingletonmodules(modules
forwhichonlyasingleinstanceexists)inasinglecontainer.Thedesignsupports
evenplacingcode,persistentdataandthreadsinasinglecontainer,whichcanbe
usedforcertainout-of-processmodules,e.g.devicedrivers.Howeverthisisnot
consideredstandardusageofthemoduleandprocessconcepts.Usingacontainer
forseveralpurposessavessomemanagementoverhead,butthisisnottheprimary
motivationfortheflexibilityofthemodule/threaddesigninSPEEDOS,whichaims
forsecuritybyusingaconsistentstructuringapproach.
SinceallobjectsinSPEEDOSstartascompositemodules,thereisusuallyafile
modulecapabilityforeachcontainerwhichisinuse.Optionallytherearealso
codemodulecapabilitiesorthreadcapabilitiesreferringtothesamecontainer.
Thedatastructures(Co-moduleTable,ThreadTableandCodeTable)forwhichno
capabilitiesexistmaybeleftempty.
Thedescriptionofthemetarightsappearsinthenextsection.Metarightsplaya
keyroleincontrollingcapabilitydistribution.Theserightscanbeusedindirectly
toimplementcertainconfinementschemes,buttheirmeaningistodefinewhat
operationsmaybeusedonthecapabilityitself.
Theconfinementandenvironmentrightsinthemodulecapabilityaugmentthe
moduleconfinementpossibilitieswhichcanbeimplementedthroughbrackets.This
conceptwillbedescribedindetailinsection6.8.3.
Thesemanticaccessrightsdeterminewhichinterfacemethodsmaybecalled
usingthismodulecapability.Sincetheremaybeaconsiderablenumberofinterface
methods,anefficientrepresentationisrequired,e.g.abitlist.Theaccessrightsare
definedasabitpatternwhichindicates(bybitposition)whichofthemethodsin
theassociatedcodemodulecanbeinvokedbythepossessorofthecapability.
Capabilitiesareusuallycreatedwithallrightsset,andduringthedistributionto
actualclientmodulestheseaccessrightscanberestricted,butnotincreasedus-
ingkernelcalls.InSPEEDOSamodulecapabilityisanecessarybutnotsufficient
prerequisiteforgainingaccesstoamodule,sincebracketsmayalsopreventthe

178

Chapter6DesignoftheSPEEDOSKernel

executionofthetargetmethod,accordingtorulesinthebracketcode.Thisrepres-
entsafundamentallydifferentphilosophythanformulatedbyNeedhamin[203].
Providingmodulecapabilitiesasuser-visibleentitiesmakesitpossibletoimple-
mentmodulesareuser-levelsimilarmoduletodirectoriescapabilityinlists,e.g.conventionalinfiledirectorysystems,modulesbut.likeSuchotherdirectorymod-
programmable.freelyareules

Metarights6.8.1.1whichAccesstomayanrestrictindividualthosemoduleoperationscapabilitypossibleisoncontrolledcapabilitiesthroughprovideditsbythemetarights,ker-
tonel.controlSincewhatthereeachareonlyoperationveryfewmaydo,operationsalthoughonthemoduleoperationscapabilities,haveitmanyissimplefacets.
Therearetwoessentialfunctionsonmodulecapabilities:
inter_module_call:Usesthespecifiedmodulecapability(alongwithanu-
ule,mericsubjectmethodtotheidentifier)varioustorightinvokefieldsanintheinterfacemodulemethodofcapabilitythe.specifiedmod-
copy_modcaptiontoa:givenGenerallydestination,copiesasubjectmoduletothecapabilitymetarightsfrominathegivensourcesourcemoduleloca-
capability.Thesourcelocationmustbeinthemodulecapabilityareaand
thedataareadestinationofamaysegment.beIneithertheinlatterthecasemodulethevaluecapabilityoftheareaorcapabilitythecannormalbe
examinedandmodified,butcannotbeusedasamodulecapability.
abilityThearefollowingallowed.metarightsGenerallyadefinemodulewhichcapabilityoperationsforaonanewlyparticularcreatedmodulemodulecap-has
alllongerrightspossibleset,onincludingathecapabilityifmetarights.aparticularThusitismetarightoftenismoreunset:interestingwhatisno
permit_copyProhibits:Ifset,copy_modcapthemoduleifunsetcapability(i.e.onlymaybeinter-modulecopiedtoanycallsotherarepossible).segment.
Suchcapabilitiescannotbemovedorcopiedinanyformwhatsoever.
permit_duplicate:Ifunsetthesourcemodulecapabilityisinvalidatedwhen
copybeingtocopied,destructivechangingmove.thebehaviourofthecopy_modcapinstructionfrom
permit_readsegment.:ThisTheallowscapabilitythemaycontentbeofcopiedatomodulethenormalcapabilitydatatobepartofexamined.anyotherIf
unset,itisnotpossibletostorethecontentofamodulecapabilityinthedata
segment.aofareaabilitypermit_normalcannot:Ifbeunsetpassedthentoanotherinter-modulemodulecallsasancannotinputbemade,parameterand.theThiscap-is

6.8MechanismsProtection

179

whichmeanttotheypreventarestored,invocationastheseofaremoduleonlycapabilitiessupposedtobystoredirectorycapabilities,modulesbutin
them.usenotshouldTtheoallowdirectorynormalmodule,useofthissuchrightiscapabilitiesautomaticallyaftertheysethaveagainbeeninareturnedcopyoffromthe
capabilitypassedbackasareturnvalueofaninter-modulecall.
uleswithpermit_distributionthesame:ownerIfunsetasthethenthiscurrentlycapabilityexecutingmayonlyprocess.becopiedThistoensuresmod-
thatthemodulecapabilityisnotdisclosedtoathirdparty.
possiblepermit_transfertopass:aThecapabilityprevioustoanothermetarightuserisandsometimesatthetoosametimerestrictive.preventItishimnot
befromset,butpassingtheniton,thebecausecapabilitytoispassoutsideitrequiresthecontrolofthepermit_distributioncaller,sothatheto
.unsetcannotpermit_distributionIfthisconditionformetarightcopyingisset,athencapabilitywithpermit_distributionpermit_distributionisignoreduntilunsettheis
violatedonce,causingpermit_transfertobeunsetbythekernel.
notonMetarightsthemoduleexclusivelyitself.controlOperationsoperationssuchasonthecreating,actualcopying,modulerenamingcapabilityand,andde-
theletingvirtualmodulesmemoryare,theandtaskmayofthusotherbemodulescontrolledthatbyrelatethetosemantictheaccessimplementationrightsofto
thesemakesthemanagementmodulecapabilitiesmodules.Howeverassociatedwithrenamingtheandoriginaldeletingmoduleamoduleunusable,asimplicitlythe
containerassociatedwiththemodulewillnolongerexist.
theyModulearesegregatedcapabilitiesintoareaspeciprotectedalinsectionofSPEEDOSa,assegmentwesawwhichincansectiononlybe6.4.3,inaccessedthat
usingwhicharekerneldescribedinstructions.intheTherefollowingareasections.numberofoperationsonmodulecapabilities,

CapabilitiesModuleCopying6.8.1.2Copyingcapabilitieswithcopy_modcapdoesnotneedmuchfurthercomment.
Boththesourceanddestinationmodulecapabilityarespecifiedbymemoryrefer-
ences(consistingofasegmentregisternumberandtheoffsetwithinthesegment).
Thecopy_modcapoperationhasafewadditionalparametersthatallowthevari-
ousaccessrightsfieldstoberestricted.
Theactualcopyingoperationistrivial,howevertheprecisemeaningofthe
copy_modcapinstructionisalsosubjecttothemetarightsinthesourcecapab-
ility(whichwillbedescribedinsection6.8.1.1)andthecurrentconfinementstate
6.8.3).sectionin(described

180

Chapter6DesignoftheSPEEDOSKernel

CapabilitiesModuleCreating6.8.1.3Thekernelinstructioncreate_modcapcreatesanewmodulecapability.This
instructionisprotectedbyakernelcapability.Thesoftwarethatcreatesnewcap-
abilitiesmustbetrustworthyandisthebasisforthesecurityoftheentiresystem.
Thenumberofmodulesthatpossessacapabilitythatpermitscapabilitycreation
shouldbelimited,asthemisuseisathreattothesecurityoftheentiresystem.
Generallyonlyonemoduleonanodehastherighttocreatenewmodulecapab-
ilities,theContainerDirectory.Allotherco-modulesthatneedtocreatemodule
capabilitiesshoulduseappropriateinterfacemethodsoftheContainerDirectoryin
ordertoobtainthenecessarycapabilities(butthisisanOSdesigndecision).

6.8.1.4Inter-ModuleCallandReturn
Inordertoinvokeamethodofamodulewiththeinter_module_callinstruc-
tion,entrythepointcallernumberneedsoftothepresentdesiredamodulemethod.Thecapabilityentryforpointthetargetnumbermoduleallowstheandker-the
neltoDependingcheckonthewhethertypetheofthemethodmodulecalliscapabilitypermitted,theandroottolocatesegmenttheofatargetfilemethod.module
isThemadeaccessibleinter_module_callinadditiontotheinstructioncodekeepssegmenttrackofimplementingmethodthetarget.invocationsby
placinginvocationrecordsonthelinkagestackofthecurrentthread.Thesere-
cordscontainlinkageinformationthatallowsthestateofthecallingmoduletobe
restoredwiththeinter_module_returninstruction.Theinformationassoci-
atedwithindividualinvocationrecords(e.g.parameterlists)mustbeseparately
protected,inordertopreventunwantedanduncontrollableinformationdisclos-
ure.Thelinkageinformationitselfmustbeprotectedagainstarbitrarymodific-
ations,otherwiseprotectionisrenderedineffective(e.g.thereturnaddressmay
bechanged).Thisisimplementedbynotmakingthecontentofthelinkagestack
segmentTheaccess(cf.tosectionthe6.6.2)segmentsdirectlycontainingaccessiblethetoEntrythePointcurrentListandmodule.thecodesegment
Theimplementingkernelstartstheatarget“read”methodoperationisduringsynchronisedtheviainter_module_callreader/writersemaphores.instruction
theandcodeendsthismodule.criticalThusregionmultipleintheinvocationsofinter_module_returnthesamecodeinstructionmodulearethatpossibleleaves
agerwithouttopreventlimitingtheconcurrentinvocationofexecutioncodeofthatisthreads.currentlyThisalsobeingenablesupdated.theCodeTheCodeMan-
“write”Manageroperations,synchroniseswhichthecriticalguaranteeregionthatnowhichthreadisupdatesactivetheinthecodecodesegmentsmodule.with
ateKnewernelsegmentsinstructionsontheconcernedstack.withThethestackmethodofinvocationinvocationdorecordsnotforneedatothreadalloc-is
therepresentedthreadisbycreated)onethatpreexistingcontainallsegmentsensitive(allocatedinformationbythethatThreadmustnotManagerbevisiblewhen
totheclientortargetmodule.

MechanismsProtection6.8

181

Theparameterandreturnvaluesegmentsaremanagedseparately(asdescribed
insection6.6.2),buttherearereferencesfromtheinvocationrecordstothecorres-
sufficespondingtopassparameterallandinformationreturntovalueandfromsegments.aAsmethod,longitasisthenotnumbernecessaryoftoregistersalloc-
ateparameterandreturnvaluesegmentsviatheSegmentManagerofthecurrent
stackcontainer,i.e.nullpointersmaybepassedandreturned.
cessorBoththeregistersinter-module(andofcallmoduleandreturncapabilityinstructionsregistersifallowsupportedthebycontentstheofkernelthepro-im-
plementation)tobepassed.Ifthisisnotsufficienttopasstherequiredamountof
containerinformation,asittheisalsothreadpossiblestack)totobespecifypassed.oneThissegmentallowsa(whichsymmetricalmustbeintheimplement-same
ationofparameterlistsandreturnvalues,i.e.thereturnvaluesarenotlimitedto
aThesingleparameterelementarysegmentdataitemisaspasseditistothethecaseintargetmanymoduleprogrammingwithread-onlylanguages.access,
whichpreventsthetargetfrommakingmodificationstotheparametersegment.
Theonlyinformationchannelfromthetargetmoduletotheclientisthereturn
theyvaluearesegmentalwayspassed(besidesbythevalue).contentForoftheexampleifregisters,abutmodifiedtheseversionarenotofthecriticalincomingsince
parameterlististobepassedtoanothermodule,anewparametersegmentmust
up.setandallocatedbeandlocalSegmentsvariablewhicharesegments)storedinmaytheprocesscontaincontainerpointers,but(e.g.thisparameterisnot,returnexpectedvalueto
be12frequentlyusedexceptformanagingtheinvocationstackforinternalmethod
acalls.well-designedThestructuremoduleofarethegenerallyparameterlistssimpleandandreturnthereisvaluesnoofneedtheformethodspointers.of
Thesepointersmayonlyrefertosegmentsinthesamecontainer(i.e.thecontainer
inwhichthethreadisstored)astheparameterlistorreturnvalue.Thisenforces
modules.ofisolationthe

CallLibrary6.8.1.5Thelibrary_callinstructionisverysimilartoaninter-modulecall.Themain
differenceisthatthetargetofalibrarycallhasaccesstoasegmentoftheclient
moduleviaapre-loadedsegmentregister.Theremainingsemanticsarealmost
containercompletelyasthethesame,segmentexceptpassedthatbythetheparameterclientlistmodulesegment(i.e.bothmustarerefertostoredtheinsamethe
containerofthecurrentthreadortothecontaineroftheprivatedataoftheclient
themodule).callfailsThe(similarlytargetcodeanofainter-modulelibrarycallcallmustrequireshavethethelibrarylibraryflagflagtoset,beunset).otherwise
Thereisnospecialreturninstructionforlibraries.Theinter_module_return
instructionhastobeusedinordertoreturntothecaller.Thelinkageinformation
12module,ThebutinvocationthisisatstackthefordiscretioninternalofthemethodOScallsdesignermayalsoand/orbethemanageddesignerinofthethefileinternalcontainermethoofda
invocationusedbythecompilerrun-timesupport.

182

Chapter6DesignoftheSPEEDOSKernel

storedbythelibrary_callinstructioncontainsallnecessaryinformation.The
ruleforreturnvaluesegmentsisanalogouslymodified,i.e.thereturnedsegment
mustbestoredinthesamecontainerasthepassedobjectandtheparameterlist.
Thisensuresthatinformationisnotdisclosedtoothermodules.Theviolationof
theinformation-hidingprincipleislimitedtotheclientandthelibrary.
Aspecialvariantofthelibrary_callinstructionisavailablethatalwaysin-
vokesthemodulecapabilityfortheSegmentManagerdepositedinthecurrent
process.Thisinstructioniscalledstack_sm_call,andismeanttoeliminate
theneedtopassamodulecapabilityfortheSegmentManagerresponsibleforthe
currentprocesstoeverymodule.Apartfromtheimplicittargetcapability,these-
manticsofthisinstructionisidenticaltothelibrary_callinstruction.

6.8.2IntegratingBracketMethodsintotheKernelDesign
Qualifierswithbracketmethodsprovideanimportantcontributiontoprotectionin
canSPEEDOSalsobe(cf.bracketed.chapter4).ThisThemeansprinciplethatnotisthatonlyaanycompositemodulewhichmodulecanbutbealsoallinvokedits
co-modules(seechapter5,section6.5andsection6.7)andcodemodulescanbe
listbracketed.moduleHencecapabilitybothwhichCo-modulemanagesTabletheandbracketCodeTlistableforentriesthatentrycontain.Aastandardqualifier
LCroutineinorderofthistomoduledeterminecanbewhetherinvokedthecallbyinthekernelquestioninshouldassociationactuallywithbeanIMCbracketedor
andwhichbracketmethodsneedtobeinvoked.
Thekernelneitherdefinesaformatforthequalifierlistdatastructurenorac-
cessesitdirectly,becauseaqualifierlistisarelativelycomplicateddatastructure
thatwouldalsorequirecomplicatedcodeinthekernelthatdeterminestheapplic-
ablebracketsforaparticularmethodinvocation.Insteadthemanagementofa
qualifierlistisdelegatedtoaseparatemodule.
insertItisathequalifierresponsibilitylistmoduleofthecapabilityrespectivetoaCo-moduleparticularentryManagerofortheCodeCo-moduleManagerTableto
orlistCodeitself,Table.whichThismustbeoperationmadeisthroughdifferentthefrominterfacechangingofthethequalifiercontentoflistthemodule.qualifier
numberTheformappingthefrombrackettheentrymodulepointmustnumberbeofmanagedthetargetexplicitlymodulebytothetheentryqualifierpointlist
module.IntheprogramminglanguageTimorthenameofthemethodismatched
oritsop/enqcategorisation.ThiskindofinformationisnotavailableinSPEEDOS
andmustbedefinedexplicitlybythequalifyinglist.Thekernelisunawarewhether
generalisedorspecialisedbracketsareused[149].Supportfortheseisthetaskof
thequalifierlistmodule,whichsuppliesthebracketinginformationtothekernel.
Thesequalifierlistsrepresentbothcall-inandcall-outbracketsassociatedwith
allinformationmethodsinofthethelinkagecorrespondingonthethreadmodule.stack,Theinkernelordertoneedstorepresentmaintainthecurrentfurther
stateofbracketexecution,i.e.thecurrentpositioninthebracketlist.

MechanismsProtection6.8

183

Thekernelexecutesthebracketsinthefollowingorder:
1)Firstthecall-outbracketsoftheclientcodemodule,then
2)thecall-outbracketsoftheclientfilemodule,then
3)thecall-inbracketsofthetargetfilemodule,and
4)finallythecall-inbracketsofthetargetcodemodule.
Inthecontextofsuchabracketmethod,thekernel’sbodyinstructioncontinues
innextthebracketbracketandlist,theni.e.theinvokeskernelthequeriesbracketthemethodapplicableinanestedqualifierlistfashion.moduleThisforeffect-the
ivelyiteratesthroughallqualifierlistsandeventuallythetargetmoduleisinvoked,
unlessabracketmethodreturnswithoutinvokingbody.Itisforbidden(thekernel
checksthiscondition)toinvokebodymorethanonceduringtheexecutionofa
bracketficationofmethod.theinterfaceMultiplesemanticsinvocationandofcanabetargetconsideredmethodisathreatusuallytoaseveresecuritymodi-(e.g.
Therepeatedinvocationinvocationsofbracketfromwithinmethodsaisbracketverysimilarmethod).toanormalmethodinvocation,
buttargetthemodulebracket(whichmethodmaynotoptionallybethehassameaccessastothetheparameterparameterlistlistpassedpassedbytothethe
clientqualifiermodulelistifmoduleanearlierincludesbracketthishasflag,i.e.replaceditit).determinesThewhetherinformationthereturnedbracketbyisaa
specialisedorageneralisedbracketmethod(cf.[149]).
Forbracketsthatareinvokedduetoalibrarycallitisforbiddentoaccessthe
parameterlistsand/orthesegmentintheprivatedataoftheclient.Thiswouldbe
bothOfacoursesecuritythehazardbracketandmethodswouldmayviolatethemselvesthebeinformation-hidingbracketed.Theprinciple.moduleissuing
isthethebodytargetinstructionmodule.isOtherwiseconsideredthethesituationclientisandhandledtheasifdestinationtheinvocationbracketforactuallybody
wasaninvocationoftheinter_module_callinstruction.

The6.8.3RegisterSecurityThreadThestateofathreadincludesasetofsecurityindicatorsexpressedasbitsina
(pseudo-)systemregister,theThreadSecurityRegister(TSR).Thevaluesinthis
registeraresavedinthelinkageofeachinter-modulecallandarerestoredtotheir
formervaluesoneachinter-modulereturn.TherightsexpressedintheTSRfall
intotwocategories:confinementrightsandenvironmentrights.
WhereaseachthreadhasitsownindependentsetofvaluesintheTSR,theval-
uestheyrelevantrepresenttoacanbethreadfurtherafteranreducedinter-moduleasthenewcallremainmodulevalid.executes.TheTherightsinvoca-which
tionofamoduleimplicitlyrevokestherightsintheTSRthatarenotgrantedin
theConfinementandEnvironmentRightsfieldinthetargetmodulecapability(cf.

184

Chapter6DesignoftheSPEEDOSKernel

section6.8.1).TherightsintheTSRcanneverbeincreasedexceptbyrestoration
return.inter-moduleanonThekernelprovidesaninstructionquery_tsrthatallowsthestateoftheTSR
toberepresentedqueriedbyandtheanTSR,whichinstructioncanforrefine_tsrexamplebethatusedinallowsbrackettoreduceroutines.therights
ingtheActuallytheseimplementationkernelofainstructionsconsiderablearenumberconsideredofatriviallow-levelkernelmechanisminstructions)(avoid-that
provideviolatestheindividualinformationqueryandhidingrefinementprinciple,sinceoperationstheforpropereachright.solutionThiswoulddeficiencybeto
canbeovercomebyuser-levelcode.
AforcedmethodcallisnotaffectedbythecurrentstateoftheThreadSecurity
Register,i.e.itstartswithallrights,subjecttotheconfinementrightsinthemodule
capabilityusedfortheforcedmethodcall.

RightsConfinement6.8.3.1Generallymoduleconfinementcanbeachievedusingcall-outbrackets,asde-
scribedforwardinchapterconfinement4.Usingschemescanbracketsbehastheimplementedadvantagetopreventthatrelativelyinformationstraight-from
leakingtomoduleswhichshouldnothaveaccesstothisinformation.
Bracketingisnotadequatetosolveallconfinementproblems,inparticularthose
orwherewhereaconfinedindividualmoduleuserswantactuallytoneedscontroltomakeconfinementcall-outsindifferentlyorder.toThefulfilitsSPEEDOStask
kernelcircumstancesprovidesprovidesomefurtherconfinement,relativelyinamoresimpleflexiblemechanismswaythanwhichcanbracketing.undersome
TheopportunitiesstructuretoofconfinemodulestheandactivitiesprocessesofinmodulestheinSPEEDOSwayswhicharchitecturearenotprovidespossible
inconventionalsystems.TheSPEEDOSkernelisawareofthenatureofvarious
forsegmentsexample,usedwhenbetweenathreadpersistentisfileexecutingsegments,aparticularcodesegmentsmodule.Itandcaninter-moduledistinguish,
parametersegments.Accesstoeachofthesedifferentkindsofsegmentscanbe
Theseparatelyconfinementcontrolledrightsbythecankernel,expresstherestrictingfollowingtheflowofrestrictionsoninformation.acalledmodule:

permit_enq:Ifset,thenpassinginformationoutofamoduleasreturnvaluesis
allowed.Thereturnvaluesaremadeinaccessibletothecallerofthemodule
ifthisbitisunset,preventinginformationdisclosure.

permit_op:Ifset,themethodsofamodulemaymodifythepersistentfileseg-
mentsofamodule.Ifunset,methodswhichmodifyitsstatearedisallowed.
Thiscane.g.guaranteetheintegrityofamodule.

onlypermit_filecode:Ifmodulesset,themaybemodulecalled.mayThiscontainrulesoutpersistentthatfilethemodulesegments.mayOtherwisesecretly

MechanismsProtection6.8

185

storeinformationinitsprivatedata,disclosinginformationtootherusers
whohaveacapabilityforthemodule.
permit_nonparam_calls:Ifset,acalledmodulemaymakecallstofurther
modules.Ifunset,modulesmaynotbecalled,unlessthemodulecapabilities
forthemhavebeenpassedasparametersandpermit_param_callsisset.
permit_param_calls:Ifset,thecalledmodulemaycallmodulesforwhich
modulecapabilitieshavebeenexplicitlypassedasparameters.Ifunset,even
modulescorrespondingtomodulecapabilitiespassedtoitcannotbeinvoked.
Theserestrictionsaree.g.sufficienttoexpressthataneditorprogram(which
doesnothaveitsownprivatedata)mayaccessandmodifyatextfile,forwhich
amodulecapabilityispassedasaparameter.Othermodulesmaynotbecalled,
whichguaranteesthatnosecretfilecanbecreatedbycopyingthetextfilecontent.
Howeverthissetofrestrictionsisnotsufficienttoimplementmorecomplicated
confinementrulesthatapplytothemodulesusedbythetargetmodule(i.e.ifcalls
arepermitted),e.g.iftheprimarymoduleisaprogram.Forfurthermodulescalled
bytheprimarytargetmoduleoneoftwosetsofthefollowingsecondaryconfinement
rightsapply,dependingonwhetherthecalltoafurthermoduleusesamodule
capabilitypassedintheparameterlistoracapabilitystoredinthemoduleitself.
Notethattheseareseparaterights,despitethesimilarnamingusedasinthe
descriptionabove.Therestrictionsavailableforsecondarymodulesare:
permit_file:Ifunset,thenfurthermodulesmaynotcontainprivatedata.
permit_op:Ifunset,thenfurthermodulesmaynotbemodified.
permit_enq:Ifunset,thenthereturnvaluesfromfurthermodulecallsaremade
inaccessible.Thispreventsinformationdisclosurethroughreturnvalues.
permit_calls:Ifunset,thenfurthercallsarenotallowed(iftheyareallowed,
thenthesecondaryconfinementrightsapplysimilarlytofurthermodules).
Theconfinementrestrictionsthatcanbeexpressedusingprimaryandsecondary
confinementrightsarequitecomplex.Notethatdifferentkindsofconfinementcon-
ditionscanbespecifiedbytheconfinementrightsandbyusing(call-out)brackets.
Confinementrightsapplytothewholemodule,limitingcallstooperationsand/or
enquiries.Howevertheconfinementrightsindifferentmodulecapabilitiesmaybe
different.Thesecondaryconfinementrestrictionspossibleusingtheconfinement
rightscannoteasilybeimplementedusingbrackets.
Thefine-grainedconfinementrestrictionsusingcall-inandcall-outbracketsare
moreflexible,astheycandistinguishbetweendifferentmethods.Theadvantage
oftheconfinementbitmechanismisthatitworksonindividualcopiesofmodule
capabilitiesanddoesnotrequiretheintroductionofbrackets,whichneedscontrol
overthequalifierlistandhasaneffectonallusersofamodule.Theimplementa-
tionoftheconfinementrightsismuchcheaperthanbracketsandisbasedonthe

186

Chapter6DesignoftheSPEEDOSKernel

restrictionofaccessrightstosegments,amechanismwhichinanycaseisrequired
modules.betweenisolationenforcetohaveeachConfinementstrengthsbasedandonbracketsweaknesses.andNoteconfinementthatbothrightsinmechanismsmodulecanbecapabilitiescom-
bined,becauseitispossibletoreducetherightsintheTSRexplicitlyinabracket
methodandadditionallyabracketmightreducetheconfinementrightsofmodule
capabilitiespassedasparametersandreturnvalues.

RightsEnvironment6.8.3.2Thekernelprovidesanumberof(unprotected)instructionsthatallowthecurrently
activethread/moduletodiscoverinformationabouttheenvironmentinwhichit
isworking.Theseinstructionsallreturnnumericalvalues(notcapabilities)which
canstructionsbeareparticularlyoftenusefulusedinforbracketcheckingmethods.securityInrequirements.particular,theThereforefollowingthesebasicin-
environmentalqueryinstructionsarealwaysmeaningful:

current_filereturnsthemoduleidentifier(includingtheco-modulenumber)
co-module,currenttheforcurrent_codereturnsthemoduleidentifier(includingthecodenumber)forthe
module,codecurrentcurrent_threadreturnstheprocessidentifier(includingthethreadnumber)
thread,currenttheforcurrent_epreturnstheentrypointnumberofthecurrentlyexecutingmethod,
calling_filereturnsthecontainernumberforthecallingfilemoduleandthe
indexvaluefromtheusedmodulecapability,
calling_codereturnsthecontainernumberforthecallingcodeandtheindex
valueofthecodecapabilityand,
calling_epreturnstheentrypointnumberofthecallingmethod.
Duringtheexecutionofbracketmethods,afurthersetofenvironmentalqueries
becomesmeaningful,whichreturnsimilarinformationaboutthetargetmodule
(informationabouttheclientisavailablesinceitisthecallingmodule).These
environmentalqueriescanbeusedtoparameterisetheimplementationofacall-in
appropriately:methodbracketcall-outor

target_filereturnsthemoduleidentifierforthetargetco-module,
target_codereturnsthemoduleidentifierforthetargetcodemodule,
target_epreturnstheentrypointnumberofthetargetmethod.

DriversDevice6.9

187

Thereisdeliberatelynoenvironmentalquerythatallowsabracketmethodto
discoverinformationaboutthepreviousand/ornextbracketmethod.Thebehavi-
ouralchangesimplementedbybracketmethodsshouldnotvarydependingonthe
existenceandidentityofotherbrackets.
Inadditiontoeachenvironmentalquerydescribedsofarthatreturnscontainer
numbers,thereisanenvironmentalquerythatreturnstheownerofaparticular
container,e.g.current_file_owner.Theownerofafileorcodecontainer
correspondstotheuserwhoisresponsibleforit.Likewisetheownerofaprocess
istheusertowhomtheprocessbelongs.Thisinformationisespeciallyusefulfor
securitychecks,accessmonitoringandforaccountingofresourceconsumption.
Theinformationreturnedbytheenvironmentalqueriesispartofthecurrent
threadstate,whichcorrespondsto“registers”ofthevirtualmachinethatrepresent
theentireexecutionstateofathread.Theenvironmentalqueriesrelyoninforma-
tionthatisupdatedonaninter_module_calloronathread_switch.
Likeconfinementrightsalltheseenvironmentalqueriesmaybeindividuallydis-
abled,byunsettingtheassociatedrightsincapabilitiesorintheThreadSecurity
Register,sinceinsomecircumstancesthesequeriescanbeusedtocircumventse-
curity.Forexampleaprogrammerinabankingsystemmightuseanenvironmental
righttoestablishwhetherhisprocessiswithdrawingmoneyfromanATMandif
sotosecretlypayoutabonustohimself!Adisabledqueryalwaysreturnsthe
valuezero,butneverindicatesanerror.QueryingthecurrentstateoftheThread
SecurityRegisterisconsideredanenvironmentalqueryandcanalsobedisabled.

DriversDevice6.9DeviceDrivershavenotbeenmentionedexplicitlyintheabovediscussion,because
undertheSPEEDOSkerneldesigntheyareinprinciplesimplymoduleslikeany
othermodule.Adevicedriverisspecialintwosenses.First,itneedstobeableto
handleinterrupts.Section6.6.6hasdescribedhowthisispossible.Second,itneeds
privilegedaccesstothebasichardwarecontrollingitsdevice.Howthiscanbe
providedindetaildependsonthehardwarefeaturesandprocessorarchitectureof
aparticularsystem.However,toharmonisethisrequirementfordifferentsystems
requiresageneralkernelstrategy.
Thisisprovidedintheformofdevicecapabilities,whichrepresenttherightto
accessthehardwarecontrollingadevice.Suchcapabilitiesarestoredinthemod-
ulecapability13areaofasegment(withthetypedevice)andaresubjecttothesame
metarightsasmodulecapabilities,buttheirmeaningisactuallyclosertoaseg-
mentcapability.Thecontainernumberinadevicecapabilityisreplacedbyanode
identifier,i.e.adevicecapabilityismeaningfulonlyinthecontextofaparticu-
larnode.Theremainingfields(i.e.index,confinementrightsandaccessrights)
13capabilityOftenthegivingaccesspermit_duplicatetoaparticularmetarightdeviceiscontrollerunset,toinaensureSPEEDOSthattheresystem.isonlyasingledevice

188

Chapter6DesignoftheSPEEDOSKernel

ofamodulecapabilityalsohaveadifferentmeaningandrepresenttheaccessible
hardwarecontrolresources,e.g.therighttoaccessacertainareaofthephys-
icalmemoryspace,whichactuallycontainsnomemorybutcontrolsadevice(an
implementationstylegenerallycalledmemory-mappedI/O).
Inordertoexercisetheaccessrightsassociatedwithadevicecapability,itmust
beloadedintoasegmentregister.Forthispurposethereisaload_devcapin-
struction,whichalsoperformsthecheckwhetheraparticulardevicecapabilityis
validonthisnode.Theaddressspecifiedinaparticularaccesstoahardwaredevice
consistsinprincipleofthesamepair<segmentregister#,offsetinsegment>as
foraccessestovirtualmemory.
Thereisnomeanstostoredevicecapabilitiesloadedintoasegmentregisterto
thepointerormodulecapabilityareaofasegment.Theonlywaytocopyadevice
capabilityisbyusingthecopy_modcapinstruction.Devicecapabilitiesarecre-
atedusingthecreate_modcapinstruction,specifyingtheappropriate“module”
capabilitytypealongwiththecontentsoftheotherfields.
Devicedriverssometimesneedtoexecuteacriticalregionwithoutswitchingto
anotherthread.Thisisaspecialschedulingpolicythatshouldbeimplementedby
theThreadScheduler,byavoidingreschedulesduringsuchacriticalregion.Asuit-
ablemodulecapabilitygivingaccessonlytothesemethodsoftheThreadScheduler
canthenbedistributedtoeachdevicedriverwhichrequiresthisfunctionality.

6.10BootstrappingandClosingDowntheSystem

AmajordifferencetomanyotherkernelsforpersistentsystemsisthattheSPEEDOS
kernelentirelybyitselftheisnotcontentofpersistent.thevirtualThestatememoryof.theSPEEDOSsystemisrepresented
requiredThustobootstrappingaccessitareaSPEEDOSrepresentedinsystemvirtualisnotmemorytrivial..TheBothitskernelstatemustandbetheimme-code
thatdiatelyareabledirectlytouseausedbynumbertheofkernelmodulesareandtheThreadco-modules.SchedulerThetwoandcentraltheContainermodules
Directory.Unlikethemodulecapabilitiesfortheco-modulesimplementingOS
beeitherfunctionality,includedtheinkernelthecannotkernelascomputeconstantsmoduleorpassedcapabilitiesbytheforbootstrapthese.Theyloader.must
Theothercentralmodule(theMainMemoryDirectory)isgenerallynotdirectly
needusedtobytheallocatekernelmainandmemoryposesnowhilespecialthesystemdifficultyis.Therunning.kernelnormallydoesnot
ItisimportantthedutycontainersoftheandbootstraptoconstructloadertothepopulateinitialtheMainmainMemorymemoryPagewithTable.themostThe
vitalContainermodulesDirectorythat,mustthebeThreadpresentfromSchedulertheandbeginning.theMainTheMemorycontainer(s)Directorywiththeare
fortheimplementationinitialformodulestheandpagetableprocessesalsomanagersneedandtobedevicepre-loaded.driversthatThisarepre-loadingrequired

Summary6.11

189

mustusethelaststateasrepresentedinthevirtualmemory,asthestateofthe
pre-loadedmodulescontainsessentialstructuralinformation.
DependingonthecomplexityoftheOSandhowmuchcaretheOSdesigner
hastakeninmakingtheworkingsetrequiredforstartingthesystemminimal,a
fewdozentoseveralhundredpagesneedtobeloadedbeforetheSPEEDOSker-
nelcancommencewithnormaloperation.Generallythenormaloperationstarts
byreinitialisingthedevicedriversandothernon-persistentaspectsofthesystem.
Thisincludescrashrecoveryoperationsthatperhapsneedtorollbackthestateof
thevirtualmemoryintothelastconsistentstatebeforethecrash.Thispartofthe
systeminitialisationiscoordinatedbyprogramsthatdonotthemselveshaveper-
sistentdata,beforethestateisreachedthatallowsfullfunctionalityofthevirtual
implementation.memoryEventuallythesystemprocesseswillbestartedthate.g.allowuserstoactivate
theirpersistentprocesses(cf.section3.3.7).Theentirestateofmodulesandpro-
cessesisstoredinthepersistentvirtualmemoryanddoesnothavetoberecreated.
Thisavoidse.g.theoverheadofcreatingnewprocessesfortheusers,asisthecase
systems.operatingconventionalmanyforInordertoterminatetheexecutionofthekernelthereisakernelinstruction
shutdown.Itsuserequiresthepossessionofakernelcapabilitywhichcontainsthe
righttousethisinstruction.Thisinstructionisusedasthelaststepintheshutdown
ofacompleteSPEEDOSoperatingsystem,afterthestateofthepersistentvirtual
up-to-date.broughtbeenhasmemory

Summary6.11TheSPEEDOSkernelenforcesanoveralloperatingsystemandapplicationdesign
basedoninformation-hidingmodules,incontrasttotheMonashPasswordCap-
abilitySystemandrelatedcapability-basedoperatingsystems,whichstopatthe
segmentcapabilitylevel.ASPEEDOSmodulemayonlyaccessitsownprivatedata
directly,andaccesstodatastoredinothermodulesispossibleonlybycallingone
oftheirinterfacemethods.Modulesreplacetheprograms,librariesandfilesin
conventionalsystemswithasingle,uniformsoftwareentity.Processesandthreads
representactivityinSPEEDOS,whichimplementsthein-processmodel.Modules
andprocessesarestoredincontainers,whichprovideauniformabstractionrep-
resentingasubstantialobjectinpersistentvirtualmemory.
ThekeyelementsoftheSPEEDOSkerneldesignarethesupportforbracketing
andcompositemodules.Bracketingsupportstheimplementationofhighlysecure
systems,whichareatthesametimeflexibleandextensible.Compositemodules
arethebasisforreducingthekernelcomplexity,bydelegatingmostfunctionality
(exceptsecurity-relatedfunctions)tousermodules.
Delegatingfunctionalitytomodulesandco-modulesnecessarilymakesthede-
scriptionofthekernelmorecomplicated,becausethemoduleinterfacesusedby
thekernelareanimportantpartofthekernelspecification.Howeverdelegation

190

Chapter6DesignoftheSPEEDOSKernel

isthekeytotheseparationbetweenpolicyandmechanismanditreducesthe
complexityofthekernelimplementationgreatly.Kernelinstructionsareshortand
executequickly,sincedelays,e.g.duetopagefaulthandling,arenotconsidered
instruction.kernelaofpartTheOSdesignerisfreetoimplementwhateverisdeemedappropriateforthe
delegatedfunctionality.TheSPEEDOSkerneldesigndoesnotenforcethedesign
ofasecuresystem.ThekernelmaybeusedtodeliberatelyconstructanOSthatis
insecure,butthisisnotassumedtobethetypicalcase.Someelementsofasecure,
persistentOSdesignusingtheSPEEDOSkernelwillbedescribedinchapter7.
Specialcarehasbeentakenthatthekerneldoesnotinterfereunintentionally
withtheresourcemanagementimplementedattheuserlevel,e.g.bythescheduler
andvirtualmemoryimplementation.Whileacompletelynon-blockingkernelis
slightlymoredifficulttoimplement,ithasmanypropertiesthatjustifythateffort.
Theinter-modulecalloperationisthemostcomplicatedpartofthekerneland
iscertainlymorecomplexthanmostmessagepassingserviceimplementationsin
amicrokernel.Thisisexclusivelyduetothehigherlevelofprotectionachievable,
notanindicationofaninherentlymorecomplexoperation.
Protectionisimplementedinseveralvariants,fromrelativelystaticmodulecap-
abilitiestofreelyprogrammablebracketmethods.Thisisnecessaryforsoftware
designedforcontinuous,reliableoperation.Nodesignerhasperfectforesightto
defineallprotectionconditionscorrectly,takingfuturemodificationsintoaccount.
Thekernelsupportsreplacingsecurity-criticalsoftwareelementsandprotection
definitionsatrun-time,inordertosupporttheimplementationofacorrectedpro-
tectionsystemwithoutservicedisruptions.Thisisanidealbasisforahighlyflex-
ible,extensibleandsecuresoftwaresystem.
TheSPEEDOSkernelimplementsavirtualmachinethatsupportsanorthogonal
implementationofsegmentationandpaging.Allsoftwareinthesystem(exceptthe
kernelthatimplementsthevirtualmachine)isrepresenteduniformlyasmodules
withsemanticinterfacesinthevirtualmemory.Thisavoidsthesoftwarespecifica-
tionandstructuringproblemsidentifiedbyParnas.
ThewholedesignoftheSPEEDOSkernelemphasisesstructuraluniformity,or-
thogonalityandsimplicity.WhilesomeelementsoftheSPEEDOSkerneldesign
havebeenusedinotheroperatingsystemsandkernels,thebiggestimprovements
areduetotheintroductionofbracketsandco-modules.Thesestructuralchanges
allowahighlevelofprotectionincombinationwithahighflexibilityintheOS
implementation.TheusuallysharpdistinctionbetweenOSandapplicationisre-
placedbyacontrolledcooperationofboth.
ThereisstillplentyofroomfordifferentSPEEDOSkernelimplementationswith
differentperformancecharacteristics.Itisnotassumedthatasinglekernelimple-
mentationisapplicableforallhardwareplatforms,rangingfromsmallembedded
systems.mainframepowerfultosystems

Chapter7

KernelSignificantDesignEffectsonanofOStheSPEEDOS

191

ThetionalitySPEEDOSorapplicationkernelbyitselfsoftwaredeliberatelystructure.doesInthisnotchaptersuggestasomeparticularelementsOSoffunc-an
OScausebuilttheongeneralthekernelOSaredesignisoutlined,similartoillustratingtheitsMONADSflexibility[130,and131]andextensibilityGrasshop-.Be-
pertural[51,52,modifications53]operatingrelatedtosystems,thebrackettheanddiscussedco-moduletopicsfocusconcepts.mainlyonthestruc-
compositeCharacteristicmodulesfeaturesandoftheco-modulesOSaretowhichdeterminedthebykernelthedelegatesimplementationpolicy-relatedofthe
thefunctions.virtualThememorymostimpleimportantmentationmodulesandthefromanthreadinfrastructuralscheduler.pointHoweveroftheviewman-are
agementofthemodulestructuresrepresentede.g.bytheCo-moduleManagerand
thequalifierlistsplayanimportantroleinthesecurityoftheoverallsystem.
oftenFornottherelevant.programmerTheofadesignernormalmayapplicationnormallythesespecifyOS-relatedappropriateco-modinterfacesulesareto
themodulesthatcomprisehisapplicationsoftwaresystemwithoutworryingabout
ofthethepreciseOSabstractionssemanticsofusuallythewillOS-relatedalreadyprovideco-modules.theTherequiredstandardfunctionalityimplementation.Ifthis
ise.g.notthethePagecase,TablethedesignerManager.simplyhastospecifyanalternativeimplementationof

7.1UniformPersistentDistributedVirtualMemory

TheageraresimplesufficientinterfacestototheimplementContaianerveryDirectorypowerfulmodulevirtualandmemorythePageTabstraction.ableMan-All
memorypersistent.Thestoragepersistent(includingstorageisremovablestructuredmedia)isuniformly,regardedandasmaypartcontainofthemodulesvirtual
andprocesses,representedbysegmentsandpagesinthevirtualmemory.
presentComputationinmaintakesmemoryplaceoninatheparticularpartofnodetheinavirtualdistributedmemorythatSPEEDOSiscurrentlysystem.
Distributedpersistentvirtualmemory(cf.[137,139,106,107])isimplemented

192Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

byresponsibilitytransferringofthepagesContainerstoredonDirectoryremotediscsmoduletoontheeachrequestingnode.node.Thisisthe

ModulesDirectoryContainer7.1.1ThepurposeoftheContainerDirectoryistomaintaininformationaboutallcur-
rentlyexistingcontainersinaSPEEDOSsystem.Ofcourseitisunrealistictoassume
acompletelycentralisedimplementation.GenerallytheContainerDirectorydeleg-
aatessingleitsdiscfunctionality(seeFigureto7.1).modulesSuchwhichaDisceachDirectorymanageisthenormallyinformationstoredonrequiredthediscfor
responsible.isitwhichfor

DirectoryContainer

DirectoryDisc

1Disc

2Disc

#108#111

#128#137

DirectoryDisc#202#217#243

#299#268

Figure7.1:ContainerDirectorystructuremanagingtwodiscs
Suchanorganisationissuitableforbothfixedandremovablemedia,andguar-
anteestainersarethattheavailable.managementTheDiscinformationDirectoryisisalsoavailableasuitableaslongplaceastheformamanagingnagedcon-the
pageTheallocationdiagramonafocusesonparticularthedisc,structuralincludingtherepresentationlistoffreeofthepages.informationabout
thelocationofcontainersandneglectsthestructureofthemanagementmodules,

7.1UniformPersistentDistributedVirtualMemory

193

whicharethemselvesheldincontainers.ThereisacentralContainerDirectory
modulepernodewhichcontainsmodulecapabilitiesfortheDiscDirectoryofeach
disccurrentlyon-lineatthatnode.Thegreyarrowsdenotethatthelocationin-
formationofthecontainersonthediscisstoredintheDiscDirectorymodule.
InadistributedvirtualmemoryimplementationtheContainerDirectorymodule
providesaservicetolocatethenoderesponsibleforaparticularcontainer.Thisin-
cludessupportforremovablemediathatarecurrentlyaccessiblethrougharemote
node,i.e.aremovablemediummaybeusedregardlessofitsphysicallocation,
providedthatitiscurrentlymounted.
TheinspirationforthestructureoftheContainerDirectorycamefromthevirtual
memoryimplementationintheMONADS-PCsystem.IntheMONADSsystemthere
isa(well-known)container0oneachdisc,whichcontainsthe“bootstrap”inform-
ationforaccessingaparticularcontainer.Thisisdirectlyaccessedbythevirtual
memoryimplementationintheMONADSkernel,butisdelegatedinSPEEDOS.
Directaccesstocomplicateddatastructuresisconsideredaviolationofthe
information-hidingprincipleinSPEEDOS,thusthedesignusesmodulesratherthan
rawcontainers.Container0isthestoragelocationfortheDiscDirectorymodule,
whichcontainstheinformationrequiredbythekerneltofindthecontainersin
thepartofthepersistentvirtualmemorystoredonaparticulardisc.Itcontains
conceptuallythesameinformationasthecontainer0inMONADS,buttheactual
hidden.isrepresentationinformationMaintainingtheContainerDirectorythroughamoduleoneachdisclimitsthe
impactofe.g.adisccrash,asonlythecontainersonthatdiscareaffected.Assum-
inganup-to-datebackupcopy,itiseasytorecoverfromthissituation.
TheContainerDirectoryhidesfromthekernelthedetailsofthecontainernum-
berinterpretation.Thekerneldoesnotneedtoknowtheprecisemeaningofacon-
tainernumberanditsrelationtotheactualstoragelocation.TheOSdesignercan
decidewhichnamingschemeisappropriateinaparticularsystem.Thenodesin
adistributedsystemhavetoagreeonanunambiguousnamingscheme,ofcourse.
DuetotheintrinsiccomplexityofarealisticDSMimplementation,thisisnotana-
lysedindetailinthisthesis.
TheContainerDirectorycommunicateswithotherContainerDirectoriesonre-
motenodes,inordertolocatecontainersandtotransferpagesthatarestored
remotely.Thismustbeimplementedusingexplicitnetworkcommunication.A
designalongthelinesproposedbyHenskensisonepossibility[106,107,289].
Ifapreviouslyunusedcontainerisaccessedforthefirsttime,itisthetaskofthe
ContainerDirectoryincooperationwiththerespectiveDiscDirectorytoloadthe
pagesofthecontainerwhichallowlocatingthecorrespondingPageTableManager.
ItisgenerallysufficientiftheDiscDirectoryknowsthelocationofthepagescom-
prisingtheCo-moduleTable.WhiletheCo-moduleTableofaparticularcontainer
isbeingloadeditisnotpossibletouseitsPageTableManager.TheDiscDirectory
determinesthepagingstrategyforthepagesoftheCo-moduleTable.Generally
theDiscDirectoryonlyneedstoknowasmallsubsetofthepagetableforeach
containeronaparticulardisc,sincetheCo-moduleTableisnotparticularlylarge.

194Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

7.1.2PageTableManager
Thekerneldoesnotenforceanyparticulardesignforthisco-module.Whilethe
thegenerallocaldesigndetailsofofthethevirtualvirtualmemorymemoryisorganisationdeterminedforbyatheparticularContainercontainerDirectoryare,
thedefinedtypicalbytheaccessPageTpatternableforManagerdataheldofinthatitscontainercontainer.,Thisusingmaythistakeintoinformationaccountfor
pageprefetchanddiscarddecisions.Thiscanimprovetheperformanceofthe
implementation.memoryvirtualAdrivers)PageitTmayablebeManagercounterproductivecouldtakeintotomakeaccountallthethatforprivatesomedatamodulespersistent.(e.g.Devicedevice
driverssupportedoftenhavehardwaretostoredevice.aTheratherstateofcomplicatedadeviceisrepresentationoftennotofthepersistentstateof(i.e.theit
alwaysstartsupinthe1samestate)andmaybepartiallydiscardedatshutdown
.lossinformationwithoutules,Ine.g.someadriversituationsforathisgraphicsnon-persistencecardmaynotcouldstoreeventhebecontentexposedoftothetheframeclientbuffermod-
acrosswindows.reboots,Thisitshowsmaythatinformitmakestheclientsensetoapplicationsimplementthatvarioustheyneedlevelstoofredrawpersistencetheir
indifferentpartsofasinglesoftwaresystem.
Persistencedoesnothavetobeentirelyautomatic,andtheprecisesemanticsis
determinedbytheimplementationoftheindividualPageTableManagersandthe
resourcemanagementmodulewhichtheyuse.Itise.g.possiblethattheoldstate
ofaoperationmoduleisisinvokedretainedonbythePstoringageTablemodifiedManagerpages.separatelyuntilanexplicitsave
tionalSuchasystem,designexceptwouldthatbetheratherinternalsimilartorepresentationtheexplicitneedsavingnotofbefilesintransformedaconven-into
afilerepresentationbytheapplication.
anItisevenimplementationpossibletowithaimplementseparateapersistentcompletelyfilestore.non-persistentModulessystemcanbyanddefaultrevertbeto
temporaryobjects,requiringtheprogrammertoexplicitlymakethempersistent.
Howeverauthenticationthereofwouldusers,beifitseverecouldnotbeimplicationsassumedforthattheprocessesprotectionaresystempersistent.andthe

7.1.3MemoryAllocationwithinaContainer
Thegeneralprinciples,problemsandsolutionsthatarisefromtheimplementa-
tionofsegmentcreationattheuserlevelhavebeendescribedinsection6.4.4.In
thissectionapossibleimplementationisoutlined,viaaSegmentManagerlibrary
.containereachwithassociated1drivers,Thiswherenon-persistentitwouldaspectbeofimpossibledevicetodriverselimiautomaticallynatesthemakethecircularentiredependencystateofpersistent.thediscThedevicstatee
ofthediscdriverismodifiedwhileitwritesdatatodisc,whichcouldpotentiallyleadtoanendless
s.pagedirtyflushingloop

7.1UniformPersistentDistributedVirtualMemory

195

tainerTheandSegmentitpossessesManagertheisrightsolelytocreateresponsibleforsegments.creatingThenewkernelsegmentscapabilityinitswhichcon-
representsthisrightandthestateoftheallocatormustbeprotectedagainstun-
wantedaccessormodification,otherwiseitwouldbeimpossibletoguaranteethat
asegmentslibrarydowithnotitsownoverlap.privateThedatarepresentationfulfilsallofthesetheallocationrequirements.Itimplementationalsohastheas
advantagethatdifferentallocationstrategiescanbeusedindifferentcontainers.
TheSegmentManagercanprovideamethodtotriggergarbagecollectionwithin
athefilepointercontainerareas.TheofallgarbagereachablecollectorsegmentsusestothestatedetermineofthetheSegmentlivenessofManagereachcur-and
rentlyallocatedsegment.Segmentsthatarenolongeraccessiblearedeletedand
asreturnedfreebytothereturningfreethemspacetolist.thefreeCompletelistpagesmanagedthatbyarethenolongerContainerinuseDirectoryare.markedSim-
ilarlytheMainMemoryPageTablemayneedtobeupdatedwhenasegmentis
deleted,freeingthemainmemorypageframesthatusedtoholdthesegment.
encesItinmustthebesegmenttakenintoregisters,accountreferringthatatocurrentlysegmentsactivethataremodulenotmayreachablehavethroughrefer-
pointers.Additionallythegarbagecollectormaybeexecutedconcurrentlytothe
memoryallocationfunctions.Appropriatesynchronisationisrequired.
Alimitedformofgarbagecollectionisneededbyanyimplementationofthe
beSegmentreuseduntilManagerthe,lastbecausereferencethespacetoitisoccupiedalsobydeleted.aThisdeallocatedappliessegmentevenifmustexplicitnot
createddeallocationtemporarilyof.segmentsisOverlappingsupported,segmentsaswouldotherwisenullifyoverlappingtheprotectionsegmentsofmaypointersbe
capabilities.moduleand

ContainersMigrating7.1.4Itisunrealistictoassumethatcontainersdonothavetobemigratedtoadiffer-
entmigrateddiscornodecontainers.intheThelifetimeContaineroftheDirectorysystem.isinThusitprinciplemustthebesuitablepossibletoplacelocatefor
storinginformationaboutmigratedcontainers(whichcanbeusedasamechan-
itismmightformigratingdelegateathistomoduleotherwithoutmodules.changingTheitsContaineridentifier),Directoryalthough(orinapracticerelated
found.module)InthusthecaseneedsoftoamaintaindistributedhintsSPEEDOSwhereasystemmigratedaglobalcontainernamingcanbeserviceactuallycould
identifythecurrentlyresponsiblenodeforaparticularcontainer.Thepossibilit-
iesfreelyarebytheunlimited,OSasdesignerthe.implementationoftheContainerDirectoryisdetermined
considered.ContainerItismigrationequallyisimportantrelevantnotforanonlyisolatedwhenasystemdistributedthathasSPEEDOSseveraldiscs.systemIfisa
disccontainercanisreflectmovedthis.TfromooneeliminatedisctotheanotherunrealistictheContainerassumptionDirectorythataontheparticularoriginaldisc

196Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

remainsinoperationforever,theremustbefurthermechanismsimplementedin
theContainerDirectory,e.g.movingtoanotherdisctheDiscDirectoryofadisc
thatistobetakenoutofservice.

7.1.5StabilityofthePersistentStore
Anotheraspectoftheimplementationofapersistentstoreisitsstability.Thesystem
mayregularlycreateasnapshotofthepersistentmemory.Thisrequirescoordina-
tion[106,125]betweenthePageTableManagersofallinvolvedcontainers.
Aproblemcouldthenariseforasysteminwhichtheuserauthenticationap-
proachdescribedinsection3.3.7isused:afterasystemcrash(whichmaytake
awhiletofix)theinvolvedprocesseswouldberesettothestateinaprevious
snapshot.Henceaprocesswhichhasbeenloggedoutafterthesnapshotwouldbe-
comeactiveagain,withoutrequiringauthentication—butthelegitimateusermay
nolongerbeattheterminal!
Thisproblemcanberectifiedbyautomaticallycreatingasnapshotforeach
logoutoperation,onlyacknowledgingthelogoutifthesnapshothasbeentaken
successfully.Thisindicateshowcomplexasecure,fullyautomaticvirtualmemory
stabilityschemecanbecome,butalsoillustratesthatsuchasystemmaybeimple-
modules.user-levelthroughcompletelymentedStabilitymayalternativelybeimplementedincombinationwithatransaction
managerthatensuresthatonlyaconsistentmodulestateisvisible.Thisisnotne-
cessarilylimitedtosmall,fairlyshort-livedtransactionsasenvisagedforexamplein
thePlurix[298]system,whichuseoptimisticschemestoavoidconflictingupdates
inmostcases.Longertransactionshaveahigherprobabilityofconflictingupdates
andthusfavourmorepessimistic,lock-basedschemes.

7.1.6ReplicationofModulesinaDistributedSystem
Inadistributedsystembasedexclusivelyonapage-basedvirtualmemoryimple-
mentationthedelayscausedbythepagetransferscanbecomeabottleneck.For
entnodesperformance-criticalinthesystem.modulesUsingitisreplicasoftencanbedesirablemuchtohavefasterandseveralmorecopiesefficientondiffer-than
betheplacedimplicitclosetoconsistencythenodesalgorithmthatuseincludedthem.inThistheofDSMcoursesystem,introducesbecausetwocopiesproblems,may
consistencyandnaming.Updatingallcopiessynchronouslyisoutofquestion.
agingThedesignersconsistencyofsomeexplicitly,asmodulespartareofthewillingtoapplication.acceptInthethiscaseresponsibilityreplicasofareman-not
citly,completelyaccordingtotransparentacertaintothepolicyuser,.Insincethistheirsectionconsistencyitisassumedmustbethatmanagedreplicasexpli-are
thatexplicitlyguaranteesmanagedbyconsistencythe.TheapplicationmergingandofthatthetherereplicaisnomodulemagicstatesOSissolelymechanismthe
application.theofduty

7.1UniformPersistentDistributedVirtualMemory

197

Whatremainsisthenamingproblem.InSPEEDOSsolvingthenamingprob-
lemisthedutyoftheOSdesigner,whomustimplementthisintheContainer
Directory.Forthepurposeofnamingareplicatedcontainer,location-independent
identifiersmightbeusedwhichrepresentanentiregroupofcontainers.Alocation-
independentidentifiermustbeimmediatelyrecognisable,e.g.bydefiningthatits
mostsignificantbitisalwaysset,whereasnormalcontaineridentifiershaveitun-
set.Thisallowsthecontainerdirectorytodistinguishbetweenbothcases.
Thelocation-independentidentifiersmaythenbeusedinamodulecapability.
Suchamodulecapabilitycouldrefertooneofthereplicas.Itthenbecomesthere-
sponsibilityoftheContainerDirectoryonthelocalnodetofindanactualcontainer
withthereplicatedcontent.ForthispurposetheContainerDirectorycoulduse
aper-nodeReplicaManagermodule,whichdefinesthepropertiesofallavailable
replicas.ThisReplicaManagernormallyusesadistributednamingservicetolocate
theavailablecopiesofareplicacontainer.Itselectstheappropriatecopy,according
tolocallydefinedpreferencesandknowledgeaboutthenetworkcharacteristics.
ThekernelinvokestheContainerDirectoryasanormalside-effectoftheinter-
modulecalloperation,becausethepagesthatbelongtothelocation-independent
containeridentifierarebydefinitionnotpresent.TheContainerDirectoryinforms
thekernelwhichactualcontainernumbermustbeusedtoaccessthecontentofthe
replica.Thisensuresthattheexecutionofareplicatedmoduledoesnotinadvert-
entlyswitchtoadifferentcopywhileitisexecuting,ifforanyreasonallpagesof
thereplicatedmodulearediscarded.Thekernelitselfdoesnotknowthedifference
betweenlocation-independentand“normal”containeridentifiers.
Modulecapabilitiesforactualreplicasremainusable.Theystillrefertoapartic-
ularcopy.Thusintroducingreplicasforapreviouslynon-replicatedmoduleisan
explicitoperationandrequiresdistributingthemodulecapabilitycontainingthe
.identifiercontainerlocation-independentWhilethereplicationimplementationisbasedonthereplicationofcontainers,
theeffectisthatmodulesarereplicated.Thecopiescomprisingareplicatedmod-
uledonothavetobetrulyidenticalandmaye.g.usedifferent(butcompatible)
implementationsofthesameinterface.Asaconsequencetherepresentationofthe
privatedataofareplicatedmodulemaydifferfrom“copy”to“copy”.
Theimplementationofthereplicatedmoduleisthenresponsibleforkeepinga
consistentstate,e.g.bymergingthecontentsofthedifferentreplicasregularly.
Suchanoperationmaybeimplementedatanarbitrarylevel,eitherthroughusing
theinterfaceofthereplicatedmoduleorbyselectingaPageTableManagerim-
plementationthatiscapableofresolvingcollidingupdates.Thelattersolutionis
onlyfeasibleifallcopiesusethesameimplementation.Theapplicationsusinga
replicatedmodulehavetodefinetherequiredlevelofconsistency.
Containersinwhichcodemodulesarestoredareidealcandidatesforreplication,
astheyarenormallyread-only.Henceitisgenerallypossibletoreplicatesuch
containerswithoutimplementinganyconsistencyprotocol.Usinglogicalcontainer
numbersincodemodulecapabilitiesprovidesasimplewaytoavoidtransferring
thecodealongwiththedata,usingthelocallyinstalledcopyofthecodeinstead.

198Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

Leavingasidetheinevitablecomplexityofimplementingreplicaupdates,itis
trivialexampleincodeSPEEDOSfortodifferentimplementprocessorthereplicaarchitecturesconceptcouldentirelybeatorganisedtheuseraslevel.“replicas”.For
Thistemsprecludeillustratessuchtheflexibilityuser-levelandimplementations,extensibilityofsincethethekernel.kernelOthercontainsoperatingtoomanysys-
TheassumptionsReplicaaboutManagerthestructuremodulesofontheeachuser-levelnode(eithersoftware.implementedasco-modules
oftrollingthetheindividualcreationcopiesoforasreplicasseparateandforcompositemakingthemodules)existenceareofresponsiblereplicasforgloballycon-
known.appropriateFurthermorereplicathecontainerlocalwhenReplicaaManagerlocation-independentisresponsiblecontainerforselectingidentifiertheis
encounteredinamodulecapabilitypresentedforaninter-modulecall.Boththe
copycreationmayofinfluencereplicathecontainerssecurityandofatheSPEEDOSselectionofsystemaandparticularmustbereplicaappropriatelycontainer
andprotected.bracketsThemaySPEEDOSeasilysolveprotectionthisprotectionmechanismproblem.basedonsemanticaccessrights

ProcessesManaging7.2

TheThissectioncreationoffocusesprocessesonandcontrollingthreadsthehasexecutionbeenofalreadythreadsandmentionedtheirincooperation,chapter6.
andontherelationshipbetweenusersandprocesses.
Modulesandthreadsareorthogonalconcepts,becauseSPEEDOSfollowsthein-
modelprocessismodel,simulatedasbydiscussedassociatinginasectionthread2.3.withOnlyamodule.occasionallyThreadstheout-ofpersist-processinde-
viapendentlythreadoftheircapabilitiescurrentwhichactivityactivate(seesectionmethodsof6.6).theirTheirThreadactivityControlcanbeManagercontrolled.
intheThreadsvirtualarememoryrepresented.Thestaticallycontentinofsuchcontainersacontainerwhichareisalsodirectlystructuredaddressableinto
segments,likeothercontainers.Thisallowsthesecontainerstobetreatedvery
similarlytocontainersinwhichfileandcodemodulesarestored.
AThreadsprocessareisaintendedcollectiontoofrepresentthreadsthatconcurrentarestoredactivityinawithinsingleanprocessapplicationcontainermod-.
ule.Theprocesscontainerdefinestheownerofthethreadsinit.Thekerneland
theThreadSchedulermoduledonotassumeaparticularrelationshipbetweena
processschedulinganditsparameters,threads.e.g.Threadspriorityareorscheduledtimeslicelength.independentlyandhavetheirown

ExecutionThreadControlling7.2.1TheThreadControlManagercooperateswiththeThreadSchedulertoimplement
storesoperationsthethatschedulinggenerallyparametersaffectonlyofathreadssinglethatthread.areThenotThreadcurrentlyControlknowntoManagerthe

ProcessesManaging7.2

199

scheduler.Thescheduleronlyneedstoknowaboutthreadswhicharelikelytobe
future.neartheinscheduledEachThreadControlManagerco-modulehasinparticularaccesstotheinter-
facemethodsoftheschedulermodulethatmakeathreadknowntothescheduler
anddefinetheschedulingparametersforthethread.Theimplementationofthe
ThreadControlManagermustbetrustworthy,asitplaysanimportantmediating
rolebetweenapplicationsandthecoreOSmodules.
ClientinterfacesofThreadControlManagersaredefinedentirelybytheOSde-
signerandmayprovidearbitraryoperationsforcontrollingtheexecutionofapar-
ticularprocess.Thustheseco-modulesplayanimportantroleinthesynchronisa-
tionofprocessesandforinter-processcommunication.

ThreadsScheduling7.2.2ThekernelThreadknowstheScheduleridentityisofimplementedthismoduleasaandcentralguaranteesmoduleforthatitseachnode.methodsTheex-
uleecutewithoutimplementationbeingisinterrupted.responsibleOnforaachievingmulti-processortheappropriatesystemthelevelofschedulerexclusionmod-
betweenschedulermethodsexecutedondifferentprocessors.
Theschedulingschedulerparametersmoduleofallbasesrunnableitsschedulingthreadsonadecisionsparticularonthenode.Theknowledgeschedulingofthe
parametersdescribee.g.thepriorityofathreadanditstimeslicelength.
Ofcoursetheschedulermayupdatetheschedulingparametersofthreadsdy-
namically,accordingtotheircharacteristicsandtheprocessorutilisationinthe
maysystem.beForimplementedexamplebyreal-timedynamicallyschedulingadjustingpoliciesthesuchthreadaspriorityEarliest.TheDeadlineexecutionFirst
boundcharacteristicsorI/O(e.g.-bound)CPcanU-boundbeormeasuredI/Oin-bound)absoluteofatermsthreadof(e.g.CPUtimewhetherused.itisCPSomeU-
propertiesmaybedeterminedmoreeasily,withoutcomplicatedmeasurements,e.g.
aAnthreadaspectisI/Othat-boundhasbeenifoncompletelyaverageitdoesignorednotsousefaritsishowcompletetoimplementtimeslicethelength.popu-
larwhenthetimeslice-basedtimequantumschedulingofapolicies.particularForthreadthistheexpires.schedulerThiscanneedsbetobeeasilyinformedimple-
mentedbygivingthescheduleraccesstothedevicedrivermodulethatsupports
thethesystemschedulertimerby.Itinvokingmusttheonlybetime_expiredarrangedthattheoperationtimerofthedeviceschedulerdrivermodulenotifies
whenthetimequantumofthecurrentthreadhasexpired.Theschedulerwillthen
switchtoadifferentthreadand(dependingontheschedulingpolicyapplicableto
thisThenewfreelythread)willprogrammableselectaschedulerdifferenttimeallowsthequantum.OSdesignertoimplementasuit-
ablepoliciesforschedulinganpolicyembeddedforthesystem,aapplicationstime-sharingrunningonworkstationthesystem.oraThemainframeschedulingcom-
puterspecialisedondatabaseapplicationsareprobablyquitedifferent.

200Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

7.2.3RelationshipbetweenProcessesandUsers
Ingeneral,useofthein-processdesignallowsadirectrelationshiptoexistbetween
aparticularprocessandtheusertowhomitbelongs.Ausercanofcoursehave
severalprocessesifparallelexecutionofseveralindependentcomputationsisde-
sired.Thismustbeexplicitlycontrolledbycreatingprocessesappropriatelyand
synchronisingthemexplicitly.Withinaprocessseveralthreadsmaybecreated.
InatypicalSPEEDOSsystem,followingtheMONADSpattern,whenauseris
introducedintothesystemasingleprocess(withasinglethread)iscreatedto
representhim.Fromthatpointon,thecontainernumberofthatprocesscanbe
regardedashisidentifier.Hemaycreatefurtherprocesses,butallofthemare
markedwiththeuseridentifieroftheircreator(“owner”),thusallsuchprocesses
canbetracedtotheuserwhocreatedthem.Eachprocessandfilecontainerwhich
hesubsequentlycreatesismarkedwithhisidentifier.
Itisimportantthatthekernelprovidesatrustworthymechanismfordetermin-
ingwhichuserisresponsibleforaparticularactivityorfile.Thissimplifiessecurity
checksandaccountinggreatly.Theenvironmentalquerythatreturnstheowner
ofthecurrentprocessisthekeytoastraightforwardimplementationofallfunc-
tionsinthesystemthatneedtodeterminetheidentityoftheuser.Similarlythe
ownershipofafilecontainerdefineswhichfilesbelongtoaparticularuser.
Auserprocess(includingallthreadsintheassociatedprocesscontainer)may
beactivatedanddeactivatedasawhole.Thisisimportantforcontrollingthe
loginandlogoutofaparticularuser.Thenode-wideloginserviceisoneofthe
fewelementsofaSPEEDOSsystemthatfollowstheout-of-processmodel.Itis
responsibleforaskingtheusersittingataterminalforthenameoftheprocess
tobeactivated.Theloginservicelooksupathreadcapabilityforthename.If
theprocessisnotalreadyactiveonanynodetheloginserviceusesthelogin
operationoftheThreadControlManagerreachablethroughthethreadcapability,
whichwillmaketheprocessknowntotheschedulermodule.Itisassumedthat
theprocessisinastatethatwillimmediatelychecktheauthenticityoftheuser
thatintendstogainaccess(cf.section3.3.7).Thisauthenticationschemedoesnot
requireacentraltableofauthenticationschemesorauthenticationresponses.
Whenauserwhoiscurrentlyloggedinwantstologout,heinvokeshisAuthen-
ticationVerifiermodule,whichasthefirstoperationinvokesthelogoutoperation
oftheThreadControlManagerofthecurrentthread.TheThreadControlManager
usestheschedulertoplaceallthreadsinthelong_suspendstate,asitisnotex-
pectedthattheprocesswillcontinueinthenearfuture.TheThreadSchedulermay
notifythevirtualmemoryimplementationthatthepagesusedbythenowinactive
processaregoodcandidatesforpagediscard.Inanycasetheschedulerinforms
theloginservicethattheprocesshasbeenloggedout.
Thisdescriptionhassofarignoredthecaseofauthenticationfailure.Actually
thelogoutmethodoftheThreadControlManagerandtheauthenticationare
executedaspartofaloopintheAuthenticationVerifierthatisonlyterminatedif
theuserprovidedthecorrectauthenticationresponse.

ProcessesManaging7.2

201

Howeverthisdoesnotmeanthatitisimpossibletoimplementotherauthentic-
ationschemes.Sincetheprocessmanagementoperations(includingthelogout
operation)aredelegatedtotheThreadControlManagerassociatedwiththepro-
cess,theOSdesignermaydecidethatcertainprocessesuseatotallydifferentau-
thenticationapproach.Thisisnon-circumventable,becausetheusercannotdir-
ectlyaccesstheThreadScheduler.
WhenaprocessisdeactivatedwiththelogoutoperationoftheThreadControl
Manager,theschedulerparametersofthethreadswithinaprocessneedtobemade
persistent.ItislefttotheOSdesignerwhethertheThreadControlManagerqueries
theschedulingparametersinthelogoutoperationandsavestheminitsprivate
dataoriftheschedulermodulesavestheminitsstate.

7.2.4ImplementingUser-LevelSynchronisationProtocols
Communicationusingsharedmemoryrequiressynchronisation,topreventincon-
sistencieschronisationinistheadataspecialstructurescommunicationaccessedandvariantthatmodifieddoesbynotseveralestablishthreads.dataSyn-ex-
ulerchange,asoperations(e.g.synchronisationsuspendingprotocolsandareresumingusuallyadirectlyparticularrelatedthread).toTheinvokingSPEEDOSsched-
kernelprovidessynchronisationinstructions,buttheseinstructionshavethedisad-
usedvantagetothatimplementtheirmoresemanticsissophisticatedsimpleandfixed.synchronisationHoweverprotocolstheseattheinstructionsusercanlevel.be
Sincerelativelyfewsynchronisationprotocolsareusedfrequently,theseareideal
candidatesforcodereuse.Synchronisationprotocolsgenerallyneedaccesstoa
sharedstate.Thissharedstateismostcommonlypartofthefiledataofamodule.
aAmodulesynchronisationmayaccessprotocolthecontentmaybeoftheimplementedfiledataasadirectly.librarymodule,becausesuch
Suchlibrarymodulesmayimplementarbitrarilycomplexsynchronisationproto-
colsusingsynchronisationthekernelprotocols,synchronisationrangingfrominstructionssimpletomutualeimplementxclusionmoreorHoare’ssophisticatedmon-
itorcontextconceptoftobrackets,transactions.oftenattheTheuseofprogrammingtheseprotocolslanguagewilllevel.Thisfrequentlyallowsbeinsepar-the
theatingtheimplementationapplicationoflogictheandtheapplication.Allsynchronisation,pessimisticwhich(i.e.wouldlock-based)otherwiseprotocolsclutter
canbeimplementedonthebasisofthekernel’sbasicsynchronisationinstructions.
Inefficientcomplexsynchronisationprotocolscanbeavoidedifacombinationof
thekernelsynchronisationinstructionsanddirectinvocationofThreadScheduler
inthemethodscontextisused.ofaWThisaitingallowsListtheManagerwaitinglistassociatedmanagementwiththetobecompositehandledmoduledirectlyto
whichsynchronisationaccessmustbeprotocolssynchronised.directly,withoutThisusingco-modulethecankernelimplementsynchronisationcomplicatedin-
thestructionsburdenofmerelywaitingasalistmeansofmanagementmanagingfromwaitingthelistsThreadSchedulerappropriately.andThisplacesremovesitin

202Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

theresponsibilityoftheapplication.ThestateoftheWaitingListManagermustbe
threadprotectedidentifiers.fromaccessThebyWtheaitingListapplication,Managersincemaythebewaitinglistsimplementedcontainasafileunprotectedlibrary
itsmoduleown,(i.e.separateitisrootinstantiatedsegment.andThestoredprivatewithdatatheoftheapplicationWaitingListmodule),Managerwhichcon-has
tainslimitstheaccessmoduletothecapabilityschedulerforthemoduleThreadtoatrustedSchedulerco-moduleandtheandwaitingavoidslists.thatThisthe
applicationhasdirectaccesstothescheduler.
Themanagementofthewaitinglistcontentissynchronisedbyusingthekernel
synchronisationinstructions.Suspendingandresumingofthreadsisimplemen-
tedidentifydirectlythebythreadusingthattheistobesuspendmanipulatedandresumebyitsthreadmethodsofidentifierthe.Threadscheduler,identifi-which
ersarenumericidentifiersonlyandshouldnotbeconfusedwithathreadcapability
(whichamongotherinformationcontainsathreadidentifier).
synchronisedEffectivelythedata,WinaitingtheListsenseManagerthatbothlibraryarestoresstoredtheinthewaitingsamelistalongcontainerwith.Thethe
WTheaitingListimplementationManagerisoftheaccessedsuspendviaaandlibraryresumecall.methodsoftheschedulermust
besumingofcommutative,athreadarebecausenottheindivisible.waitinglistThismeansmanagementthattheandtheinvocationsuspendingofsuspendorre-
andresumeoperationsisnotguaranteedtobeintheorderthatguaranteesthata
threadisactuallysuspendedwhentheschedulerisrequestedtoresumeit.
intoTheaccountimplementationthatthreadsofacanbesynchronisationdeleted.Thismaymechanisme.g.atleavethestaleuser-levelthreadmustidentifierstake
inawaitinglist.Ifathreadisdeletedthatcausedotherthreadstobeblocked,it
mustbearrangedthatoneofthemisresumed,otherwiseadeadlockoccurs.

Communication-ProcessInter7.2.5Implementinginter-processcommunication(actuallyinter-threadcommunication,
butcoursethisusenotionissynchronisationratherunusualtoandcoordinatethusthethestandard(quasi-)concurrent“IPC”notionactivityisused)ofmaythreads.of
InEachSPEEDOSmoduletothreadswhichusuallyseveralthreadscommunicatehavesharedthroughaccessthebyuseofdefinitionsharedimplementsmemory2.
protocol.communicationinter-processanCertainmodulesemphasisetheinter-processcommunicationaspectandimple-
mentaparticular,genericcommunicationvariant,e.g.amailbox.Evenstandard
e.g.modulesthesuchelectronicasmaildirectoriessystemcan[141]beuseddesignedtoforimplementtheaMONADScommunicationsystem.system,
Theprogrammeradvantagemayoffreelyusingdesignsharedhismodulesowntoprotocolimplement(e.g.formessagecommunicationpassing)isthatorthehe
2nicationExplicitnemechanism,tworkwhichcommunicationisusedistoignoredimplementinthisdistributedcontext,asitsharedismemoryconsidered.alow-levelcommu-

7.2ProcessesManaging

203

canofcourseuseaprotocoldevelopedbyothers.Inothersystemsthekernelor
theOSprovidesafixedsetofcommunicationprotocols,sothattheprogrammers
areforcedtoadapttheapplicationtotheavailablecommunicationmechanisms.
HowevertheOSshouldprovideappropriatebasiccommunicationmechanismsfor
applicationsandshouldnotlimitthefreedomoftheapplicationdesigner.

ManagementThreadDistributed7.2.6Processandthreadmanagementbecomesmorecomplicatedifseveralnodesare
theinvolved.potentiallyThelongconceptsdelaysremainofnetworkunchanged,butcommunicationthe(andimplementationthenumerousneedstoerrortake
sourcessuchasbrokenlinks)intoaccount.
Anexampleistheuseofasemaphorestoredinasharedmodulebythreadsrun-
ninganotherondthreadifferentonanodes.differentIfanodethreadmaye.g.needinvokestothebecomeVrunnable.operationonThisarequiressemaphore,the
invocationofinterfacemethodsofaremotescheduler.ThelocalThreadScheduler
ulermust,e.g.havebyawayusingtoafindsimilarouttheservicemoduletothecapabilitynamingforservicetheusedrequiredtolocateremotethesched-node
responsibleforaparticularmigratedcontainer(cf.section7.1.4).
TheseeminglyeasiestsolutionistorelyontheusualDSMmechanismsforre-
motecausesthemodulerequiredinvocation.pagestoSimplybeinvokingtransferredatothemethodlocalofanode.remoteThisbyscheduleritselfmoduleshould
workwithoutproblems.Howevertheremotescheduler(nowrunningonthelocal
CPCPU)U.Formaythisdecideitwouldthattheinvokeresumedthethreadthread_switchshouldimmediatelyinstructionbeontheassignedlocaltoker-a
nel.responsibleTheresultforawouldremotebenodetemporarilychangedtheinconsistentlocalschedulingscheduling,incorrectlysince.ascheduler
ation.ThisThedescriptionremotenodeactuallymaynotignoredtherescheduleside-effectsuntilallcausedwritablebythepagesDSMarereturnedimplement-to
toit.beThusthereturned.executionBlockingofthethreadsschedulerontheisremoteundesirable,nodeasmayitcease,decreaseswaitingtheforprocessorpages
Bothutilisationthelocalunnecessarilyandthe.remotesystemmaybeblockedforaconsiderableamount
offorthetime.CPU.ThiscanAdditionallyresultintheunacceptableschedulersondelaysbothfornodesotherhavetothreadstrustthateachareotherwaiting,as
amaliciousforeignschedulerisathreattotheavailabilityoftheentiredistributed
system.Thereareatleasttwosolutionsfortheseandsimilarproblems:
a)ExtendtheContainerDirectorymoduleusedbytheinter_module_call
i.e.theinstructioncurrentsothatthreadthemigratesinstructiontothesupportsnodeonremotewhichtheproceduredataiscallstored.semantics,
b)Supportremoteaccessesthroughexplicitcommunicationbetweentheaf-
fecteddelegatedtoschedulers.alocalRsystemelayingthreadoperationsthathastoabeenremotesetupforschedulerthispurpose.needstobe

204Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

Theformercaseisrelativelystraightforwardtoimplement,astheunderlying
problemissimilartothereplicationofmodules.RemoteIPCinvocationshave
tobedetectedbytheContainerDirectory,whichmaythencausethethreadto
bemigratedtotheremotenode.Whetherthethreadisactuallymigratedora
surrogatethreadiscreatedontheremotenodeisnotrelevant.Animportantdetail
isthatthemigrationmustbedelayeduntilallcall-outbracketsoftheclientmodule
areexecuted,becauseatthistimethetransitionfromtheclientmoduletothetarget
performed.conceptuallyismoduleThecommonpropertyisthattheremoteschedulermoduleisneverinvokedfrom
thelocalsystem,whichistheultimatecauseoftheproblems.Infactthepages
oftheschedulermodulewillusuallybelockedintothemainmemoryofthenode
whichitcontrols,inordertopreventpagefaultsinitsfileandcodecontainer.
Bothsolutionsarebasedontheimplementationofaremoteprocedurecallser-
viceindifferentpartsofthesystem,butonlycase(a)needstomigratethreads.
Case(b)includestheimplementationoftheRPCserviceintheschedulerimple-
mentationanddoesnotmigratethreads.
Themigrationofathreadisimplementedbyremovingthethreadfromthelocal
schedulerandaddingittotheremotescheduler.Removingathreadfromthelocal
scheduleristrivial,andaddingittotheremoteschedulermustbeimplementedas
anRPCstylemethodinvocation.Thisissimilartothesecondcase,wheretheRPC
functionalityisimplementeddirectlyintheschedulermodule.TheRPCserveris
generallyexecutedbyasystemprocess.

7.3ManagingContainersandtheirContents

Inthecourseofitsactivitiesthekernelrequiresaccesstoinformationstoredin
containers,inparticulartheCo-moduleTable,CodeTableandThreadTableof
eachprovidedcontainertothe.Thekernelrelevantandontheinformationkerneldependsinstruction.ontheSettingtypeofupthemodulecontentcapabilityofa
containerisdelegatedtomodulesandco-modules,whichofcoursehavetocooper-
atewiththekerneltoavoidinconsistencies(cf.section6.6.7).Inthissectionthe
focusisontheuser-levelimplementationofthecontainermanagement.

ManagerCo-ModuleThe7.3.1TheCo-moduleTablemaycontainbothwell-knownco-modulesusedbytheOS
ofkerneltheanduser-levelco-modulespartsofthattheareOStousedsetonlyupbytheotherco-modulesmodules.ofIttheisthemoduleresponsibilityappropri-
ately,accordingtothesystem’ssecuritypolicy.
thatThasypicallyaccessthetoCo-moduletheCo-moduleManagerTisabletheonlysegment.co-moduleTheofcontentaofcompositethissecurity-module
ulesensitivecapabilitydataforstructuretheisCo-moduleprotectedManagerthroughandthethesemanticgenerallyaccessveryrightslimitedinthedistribu-mod-

7.3ManagingContainersandtheirContents

205

tionofCo-moduleManagercapabilitieswhichallowtoretrieveinformation(such
asthecodemodulecapabilities)fromtheCo-moduleTable.
WhenacontaineriscreateditmustalwayscontainaCo-moduleManager.Cre-
atinganewcontaineristhedutyoftheContainerDirectory.TheContainerDir-
ectorysetsuptheinitialcontentofacontaineraccordingtoatemplatecontainer
(cf.section5.2.3).Itispossibletoavoidincludingotherco-modules(evenaPage
TableManager)initially.ThustheCo-moduleManageroperationsdeterminehow
acompleteapplicationorOSmoduleisconstructed.
TheCo-moduleManagerisresponsibleforcreatingfurtherco-modules(e.g.the
applicationco-module)andfilelibraries,whichmeansthatitneedstobeableto
issuefilecapabilitiesfornewco-modulesandfilelibraries.Forthisitusesthe
ContainerDirectory,whichisusuallytheonlymoduleinaSPEEDOSsystemthat
hastherighttocreatemodulecapabilities(cf.section6.8.1.3).
Initially,whenanewco-moduleiscreated,itsrootsegmentinthefilecontainer
isnotallocated,i.e.itsrootsegmentpointerintheCo-moduleTablecontainsa
nullreference.InthissituationtheCo-moduleManagerinvokesawell-known
methodofthenewco-module,whichexclusivelyreturnstherequiredlengthsfor
thenormaldata,pointerandmodulecapabilityareasoftherootsegment3.The
Co-moduleManagerthenusestheSegmentManagertoallocateasegmentofthe
requestedsizeandentersitastherootsegmentforthenewco-moduleintheCo-
moduleTable.Aftertherootsegmentisallocated,itisinprinciplepossibletouse
thenewco-module.Inmanycasesthefirstmethodinvokedforanewco-module
initialisesthecontentoftherootsegment,i.e.issimilartoaconstructorinmany
object-orientedprogramminglanguages.OfcoursetheCo-moduleManagermay
alsoimmediatelyinvokesuchamethodbeforeitreturnsthemodulecapabilityfor
thenewco-moduletoitsclient.
AnactualCo-moduleManagerimplementationwilllikelyneedtomaintainmore
informationthanthebareminimumrequiredbythekernel,andwillaccordingly
haveitsownpersistentdatainthecontainer.TheCo-moduleTableisjusta(spe-
cial)segmentreachablefromtheCo-moduleManager’srootsegment.
Althoughtheideaofco-moduleshassofarbeenformulatedprimarilyinterms
ofasinglemainmodule(previouslyreferredtoasthe“applicationmodule”),there
isnomechanismwhichwouldpreventtheco-modulemanagerfromloadingthe
persistentdataofseveraldifferent(butpossiblyrelated)applicationmodulesinto
asinglecontainer.Thiscouldbeusede.g.tobundlesmalldatastructurestogether
andthusreducethepagetableoverhead.
Aspecialcaseofthiswouldbetohaveanapplicationmodulesuchasacompiler
whichineffectcreatesacodemoduleviatheCodeManager(seesection7.3.2)and
thencreatesaninstanceofthismoduleasaseparateapplication(co-)moduleinthe
samecontainer.Suchastrategycouldbeespeciallyusefulforsingletonmodules
3toItissegmentsnotinpossiblethetocurrentallocatefiletheroocontainertsegmentmaynotinthisbermeeturnedthodoftfromheco-module,co-modulesorsincepassedreferencesasa
parametertotheCo-moduleManager.ThustheCo-moduleManagermustinvoketheSegment
Manager(whichisafilelibrary)directly.

206Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

(e.g.centralOSmodulessuchastheProcessScheduler).Againthemainadvant-
ageisthatitcouldreducethepagetableoverheads.Insystemswhichprovide
fullstrategy,supportandforsomeorthogonalstrategiestobesegmentationdescribedandforpagingtheaCodefurtherManageradvantageintheofnextthis
section,wouldbethatseveralsegmentscouldpotentiallybeplacedinthesame
page(s).Thisreducestheremaininginternalandexternalfragmentationwithina
.furtherevencontainer

ManagerCodeThe7.3.2isCodeinstalledmodulesbytheheldinaCo-modulecontainerManagerare.managedTheCodeprimarilyManagerbyaisCoderesponsibleManager,forwhichcon-
furtherstructingmoduleandmanagwithingwhichtheitCodeTcooperates)ableiswhichalsoisaccessedresponsiblebyforthekernel.constructingIt(ora(or
checking)theappropriatesegmentstructureswithinindividualcodemodulesand
forthatanensuringEntryPthatointtheseListisconformpresent.toItthealsorequirementsprovidesandfortreatingdistributesdatatheasinitialcode,codee.g.
Acapabilitysingleforcodeeachcodecontainermodulemayorcontaincodelibraryseveral.implementations.TheSPEEDOS
kerneldoesnotspecifyhowtheseshouldberelatedtoeachother.However,several
Thesestrategiesarenotmightbemutuallyfollowedexclusive,forandbundlingtheOSdifferentdesignercodeoruserintoisafreesingletoimplementcontainer.
anyornoneoftheseand/orcombinethemasappropriate:

a)Thetogethercodeofcanbeseveralplacedlooselyinarelatedsingletypescontainerormoduleswiththewhichareadvantagetypicallythattheyused
shareasinglepagetable.Thisincreasesthechanceofreducingpagefaults
code.theaccessto

b)Theplementationcodesegmentsofacanbedouble-endedsharedqueuebetweencanbeseveralusedrelatedtotypes,implemente.g.athestackim-
“halfsimply”ofbytheconstructingdouble-endedanqueue.appropriateEntryPointListthatonlyusesone

c)inaMultiplesinglecontainerimplementations,providingofthethesametypeopportunityormoduleofcanallowingbeplacedthemtotogethershare
methods.theirofsome

Strategy(c)canbeusedinconnectionwithcreatinganewEntryPointListwhen
codecorrectionshavebeenmade,overwritingtheEntryPointListpointerinthe
CodeTableentry.Thisensuresthatthethreadsthatarealreadyactiveinthecode
modulecancontinueusingtheoldimplementation,whereasnewclientsofthe
moduleusethecorrectedcode.Ofcoursesuchatransparentapproachisonlypos-
sibleifthecorrectionisrelativelysmallandthestateoffilemodulesusingthecode

7.3ManagingContainersandtheirContents

207

ationmodulehadisstillsevereinaerrors).consistentThestategarbage(whichcollectorisnotwillguaranteedeventuallyiftheremoveoldtheimplement-unused
isEntrynoPlongerointListusedandbytheanyunusedthread.codesegmentsoftheoldimplementationwhenit
Sincetheoreticallycodeispossiblemerelyfortheittodatabeofamodifiedmodule(assuchdata)aswhenaitcompilerisalreadyorinlinkeruseitasis
code.Thereisanobvioussynchronisationproblem—usingthecodeandmodifying
itinkernel,parallelbutofmustthebehigher-levelavoided.OSAgain,modulesthisis(cf.largelythenotthesynchronisationresponsibilityintheofinter-the
thismoduleapproachcallisinstructionused,itisdescribedpossibleintofixsectionerrorsin6.8.1.4),theusuallyimplementationtheCodeManagertransparently.If,
insofarasthedatarepresentationremainsabsolutelyunchanged.
openThereupisthealsoapossibilitypotentialofTsecurityrojanHorsesproblem,beingasmaliciousintroduced.changesThetoasolutioncodetomodulethis
problemcanofcoursebebasedontheusualSPEEDOSprotectionmechanisms,
methods.bracketandcapabilities

Linkers7.3.3AInfairlyconventionalstaticvariantoperatingincludessystemsthethereimplicitareusetwoofmainsharedvariantslibrariesofindynamicUNIX,linking.where
tothesetlinkerupansetsupain-memorylistofimagerequiredofthelibrariesprograminthethatprogram.looksasifTheitisloaderstaticallyusesthislinked.list
Themainadvantageofthisapproachisthatasinglelibrarymaybesharedbymany
programs.InSPEEDOSthiscorrespondsroughlytoalistoflibrarycapabilities
liststoredisincompletelythecodedeterminedmodulethatatdependscompile-time,onthemusually(asbytheshownlinkerinFigurewhich7.2).preparedThis
thecodemoduleincooperationwiththeCodeManager.
Library1ModCap

ModuleCodeEntryPointListPointer

LContainer12LibraryLibrary3...libraryModCapsContainerCContainerL3ContainerL2
Figure7.2:Dynamicallylinkedprogram(semi-staticlinking)

208Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

Librarymodulesmaythemselveshavemodulecapabilitiesforlibrariesintheir
codeandusethemtoinvokelibrarymethods.Theclientofalibrarymoduledoes
notneedtoknowonwhichfurtherlibrariesaparticularlibraryimplementation
depends.Thisstrictlyadherestotheinformation-hidingprinciple.
Librariesmaybebracketedjustlikenormalmodules(howeveritisimpossibleto
accessand/ormodifytheparametersandreturnvaluesinordertoavoidviolating
theinformation-hidingprinciple,asdiscussedinsection6.8.2)andtheircapabil-
itiesalsoincludetheconfinementbits,soarbitrarymonitoringandconfinement
conditionscanbeimplemented.Untrustedlibrariescanbetightlycontrolled,e.g.
toeliminatetheopportunitytodiscloseprivateinformationofaparticularmodule.
Theotheruseofdynamiclinkingtocodeinconventionaloperatingsystemsisthe
supportforexplicitdynamiclinking,undercontroloftherunningprogram.The
programexplicitlyloadsaparticularlibraryandinvokesthelibrarycode.Sucha
softwarestructureoccursgenerallyforextensibleprograms,whichsupportplug-ins
thataddfunctionalitytotheapplication.Thiswaythefunctionalityofanapplica-
tioncanbeextendedwithoutupdatingthecodeoftheapplicationprogramitself.
Sincelibrarymodulecapabilitiescanalsobeplacedinfilemodules,theycanbe
usedtoachievethesameeffectinSPEEDOS.Theyallowsoftwaresystemstobe
constructedthatremainextensibleaftertheirimplementationhasbeencompiled.
Amodulehavingaccesstolibrarycapabilitiesstoredinitsfiledata(cf.Figure7.3)
orpassedintheparameterlistforaninter-modulecallcanuselibrariesthatdid
notevenexistwhenthemodulecodewascompiled.

ModCap

ModuleCode

ModuleFile1LibraryModCapCodeRootPointerContainerC

LContainer2Library13LibrarylibraryModCapsFContainerContainerL3ContainerL2
Figure7.3:Moduleusingarbitrary,dynamicallylinkedlibraries

formats,Thiscanbeassumingusedtothataimplementlibrarywithe.g.asoftwareknownthatinterfacesupportsisfutureimplemented.bitmapThisimageal-
lowsaspectofflexiblelibraryandmodulesextensibleplayssoftwareonlyasystemssecondarytoberoleinthisimplemented.context.Thecodereuse

7.3ManagingContainersandtheirContents

209

ManagerThreadThe7.3.4andThethecontentCodeofTaableThreadbyaTableThreadisManagermanaged,whichanalogouslycanbetotheconsideredCo-moduleanTapplica-able
tionco-moduleoftheprocesscontainer.TheThreadManagerisresponsiblefor
Forcreatingexamplethreads,theinThreadthesenseManagerofallocatesorganisingthetheirsegmentvirtualforthememorylinkagerepresentation.stackofa
thread.Thisco-moduleshouldnotbeconfusedwiththeThreadControlManager
inthesamecontainerthatisinvokedbyusingathreadcapability(cf.section6.6.1),
whichisresponsibleforcontrollingtheexecutionofthethreadswithinaprocess.
thusThreadsallthreadsareintendedwithintoonerepresentcontainerparallelbelongtooperationthesamewithinuseran.Creatingapplication,anewand
tainerthreadofisatherelativelyprocesshassimpletobeoperation,created.asTheonlymostasetcriticalofnewpartissegmentstheincreationtheofcon-a
newcapabilityforthethread(usingtheContainerDirectory)andthesettingupof
theItisinitialalsostatepossibleofthetocreateprocess.aprocessinacontainerholdingafilemodule(evena
singletonfilemodulethatstoresbothcodeandprivatedatainonecontainer).This
isespeciallyrelevantformodulesfollowingtheout-of-processmodel,e.g.device
drivers,andreducesthepagetableoverhead.
byGenerallyexecutingtheanmethodinterfacethatmethodcreatesofaanewnominatedthreadmodule,arrangesthatwhichtheisthreadspecifiedstartsby
otherparameterskindstoofthethreadthreadcreationcreationsemantics,method.e.g.Howeveraitforkisalsooperationpossiblethattoimplementduplicates
thethreadscurrentrequirethread.cooperationThreadwithcreationtheThreadsemanticsthatScheduler,createeitherimmediatelydirectlyorrunnablethrough
.ManagerControlThreadtheableTheinabilityothertooperatingselectthesystems.threadThecreationmainreasonsemanticsforthisfreelyislimitationnotisgenerallythatthreadavail-
andprocesscreationareoftentightlycoupledwiththeprocessscheduler,whichis
generallyimplementpartseveralofthethreadkernel.orTheprocesskernelcreationdesignersvariants.generallyInSPEEDOShavenotheseinclinationstructuralto
OSproblemsdesignerdoisnotfreeexisttosinceimplementtheThreadarbitrarySchedulerthreadiscreationnotpartofsemantics.thekernelandthe

ListsQualifierManaging7.3.5ingBracketmethodmethodscalls(seemodifychapterthe4).behaviourItisofpossibleexistingtodefineinterfacebracketsmethodsthatbyareintercept-activated
whenatargetmoduleisinvoked(call-inbrackets)and/orbracketsthatareactiv-
atedwhenthetargetmoduleinvokesanothermodule(call-outbrackets).
Atargetmodulecanbequalifiedbymultiplebrackets(cf.section6.8.2)which
areandheldCodeinTaablelist(cf.associatedsectionwith6.7).eachTheseentryqualifierinthelistCo-modulemodulesTdefineable(cfthe.sectionordering6.5)of

210Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

definesbracketsforwhichabracketparticularmethodmethodofofathequalifiertargetneedsco-module.tobeTheinvokedqualifierforalistparticularmodule
methodcall-outofbracketstheoftargettheco-module.co-moduleandThethekerneldefinesimplementationthe(cf.orderingsectionof6.8.2).call-inTheand
combinationofbothspecificationsdefinestheorderingofthebracketmethods
associatedwithamethodofthetargetco-module.
forward,Whilethethisdoesinterfacenottothenecessarilyqualifierapplylisttothemoduleusedimplementationbytheofkerneltheisqualifierstraight-list
module.Defininganeasilyusableandappropriatelyprotectedinterfaceisnot
trivial.Thequalifierlistmoduleneedstoprovideaflexibleandpowerfulway
todefinetherelationshipbetweenthetargetmodulemethodsandtheassociated
bracketmethodsimplementedbythequalifiermodules.
theCodeQualifierTable.listsareThusitisrepresentedpossiblebytomoduleimplementcapabilitiesthemineithertheasCo-moduleseparateTablecompositeand
modulesorasco-modulesofthemodulesforwhichtheylistqualifiers.
overheadImplementingintroducedaqualifierbythelistthroughco-modulesaco-moduleimplementingismoretheOSefficient,aspectsastheisalreadystorage
writtenoff.Asinglequalifierlisttypicallycontainsonlyasmallamountofdata.
thisHoweversituationaitisqualifyingbetterlisttocanuseabeusedseparatetodefinemodule,qualifiersbecauseitforcannotseveralbemodules.guaranteedIn
thatthemodulethatcontainsthequalifierlistco-moduleisdeletedlast.
tionTheofdesignerqualifieroflists.theTheapplicationexpectedsystemlifetimehasoftotheselectprotectedtheappropriatemodulesplaysrepresenta-thekey
roleinselectingeitheraseparateorintegratedqualifierlistrepresentation.

7.3.6ImplementationIssuesinBracketMethods
thatThehavekernelaccessrestrictstoaccessparameters.toparameterTheparametersegmentsbyasegmentclientcanmoduleonlybeorthemodifiedbracketsby
thecaller,i.e.onlyread-onlyreferencesarepassedbytheinter_module_call
newoperation.parameterBracketsegment.methodsThisthatpreventsneedtomodifyinformationtheseleakagesegmentstohavebrackettocreatemethodsa
thoseinvokedbrackets.earlierinThistheproblembracketingdoesnotsequence,applytoasreturnexecutionvaluewillsegments,eventuallyasthesereturnmayto
onlybepassedinonedirection,becausethebodyinstructioncanonlybeinvoked
onceinaparticularbracketmethod.
Recentlyageneralisedvariantofusingbodywasfoundusefulinthecontext
ofingabodyimplementinginvocationtransactionstoadifferentusingbracketstargetobject[154](ininTtheimor.contextThisoftherequirestransac-relay-
tionexampletotheshadowcopyofanobject)byusinganinvocationoftheform
targetObject.body(...).Thiscanbeusedtoreplaceamodulewithadiffer-
entinvocationinstanceofthespecifiedoriginalbythetargetbracketobjectmethodusingbodyexplicitly.anddoesnotprecludethe

7.3ManagingContainersandtheirContents

211

InthroughSPEEDOSthenormalsuchmethodcallinter_module_callrelayingtoaoperationdifferentandmodulenotasainstancespecialishandledvariant
ofthebodykernelinstruction.Themodulecapabilityforthenewtargetmodule
inedinstanceusingmustthebeheldenvironmentalbythebracketqueryandtarget_eptheentry.pointAdditionallynumberthecanbebracketdeterm-that
turnimplementsvalues(i.e.thisitrelaymustbeafunctionalityspecialisedmusthavebracket),accesstootherwisetheitparameterwouldnotlistbeandablere-
tofromaccessthethe“replacement”parametersandmodule.returnvaluesandthuscouldnotforwardthemtoor

InterfaceModuletheDescribing7.3.7InconceptSPEEDOSofathetypeasnotionofsupportedabymodulemanyinterfaceprogrammingismuchcoarserlanguages,thanwhichthedetailedincludes
themuchsignaturesburdenonofallthemethods.methodAtinvocationtheOSlevel,implementationthislevelofinthedetailkernel,wouldputwithouttoo
achievingasubstantiallymoresecuresystem.
FromtheviewpointoftheSPEEDOSkernel,theonlyinformationrequiredto
Theinvokeamethodmethodcallofamechanismmoduleallowsisamoduleparameterlistscapabilityandandreturnanentryvaluestopointbenumberpassed,.
butThethekernelconsequencedoesisnotthatcheckeachthemodulecontentoftheseimplementationstructures.mustscrutinisethepara-
meterLikewiselist,theasareturnmaliciousvaluesorshouldfaultybeclientcheckedmaybeforpassingplausibilityinvalidbytheparameterclientvalues.mod-
ule,thisinsmallaneffortoverheadtoimproveshouldthebeoverallnegligible.systemIfanresilience.errorinInthesecheckssecurity-sensitiveisdetected,code
itcanmodules.beThetemporarilylong-termfixedsolutionthroughisofaddingcoursetofixcustom-writtentheerrorinbracketsthetosoftware.theaffected
Itnamesmayandbetopreferablehaveforknowledgesomeofpartstheofthestructure(user-level)oftheOStoparameteruselistandhuman-readablereturn
valuelist,supportingtheessentialprogramminglanguagetypeswhichareused
toconstructparameterlistsandreturnvalues.Generallythecommand-lineinter-
preter(CLI)needssuchinformationtoconstructcallstoarbitraryinterfacemeth-
odsleastoftheatypesmodule.oftheInorderindividualtoprepareparameters.theparameterSimilarlylistthetheCLICLI(whichneedsistoveryknowsimilarat
toofanthereturninterpretedvaluesinobject-orientedordertostoretheprogrammingdataforlaterlanguage)processing.needstoknowthetypes
Allinterpretertheandrequireditsassociatedinformationmayconfigurationbeentirelymodulesmanaged[76].bytheAlternativelycommand-languagethedirect-
orycontainingmodulesthemaytypestoreandescription,additionalwhichismoduleusedbycapabilitytheCLI.ineachentryforamodule
iteThemoduleinterfaceitself,whichdescriptionhasmaytheactuallyadvantagebethatstoreditisinalessco-modulelikelythatofantheincorrectcompos-

212Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

interfacementationofadescriptiontypeisconceptused.ispossibleWhicheverentirelyapproachattheisuserused,alevel.moredetailedimple-
method,Someinbracketsordertomayperformalsoneedtoappropriateknowthesecuritydetailschecks.ofthesignatureofthecalled
typeThecheckingprogrammingbymakinglanguagemoduleusedtocapabilitiesimplementatypedmodulesentitymay,alsodistinguishedenforcebystricterthe
interfacetypeofthemodule4.Thiswouldpreventassignmentstoincompatible
usemoduleofacapabilitytype-incompatiblevariablesmodulewithincapabilitymodules.andconsequentlytheunintentional

IssuesGlobal7.4Sorelativefarinthisisolationchapterfromtheeachuseotherof.ThisindividualinmostcasesmechanismsreflectshavethebeenwaythediscussedOSandin
itsuserswillviewthem.However,someissuesrequiredesignerstotakeamore
globalviewofasystem.Wenowdiscusstwosuchthemes:protection/securityand
management.resource

SecurityandProtection7.4.1SPEEDOSprovidesanumberofbasicmechanismswhichallowsystemadministrat-
orsand/oruserstoprotecttheirinformationandotherresources.Aswesawin
theirsectionown7.2.3,itauthenticationcanbearrangedmechanismsthat(asusersinauthenticateMONADS).Oncethemselvesloggedonin,logintheyusinghave
avarietyofmechanismsathand,includingmodulecapabilities,bracketmethods,
environmentalqueriesandtheconfinementtechniquessupportedbytheThread
SecurityRegister.Theseshouldbeseenascomplementingeachother,asthefol-
.showexampleslowingThemainweaknessofmostcapability-basedsystemsisthedifficultyofrevoking
capabilities.DirectrevocationinthetraditionalsenseisalsodifficultinSPEEDOS,
butwhichthisinistheirnotabracketsmajoruseproblem,environmentalbecauseitisquerieseasy(e.g.toprocessdevelopownerqualifying,callingmodulesmod-
ulemoduleororcallingthecode)identifytoofascertainthecodethemoduleidentityofassociatedtheuser,withthetheidentitycallingofthemodulecallingto
establishwhetheranyoftheseisnotpermittedtomaketheIMCorLCcurrently
beinglongerhaveattempted.access.TheThisisqualifierofcoursemoduleamuchcontainsmorealistflexibleofidentitiesformofwhichrevocationshouldthanno
usewhatofiscapabilities,traditionallybracketunderstoodmethodsasandrevocation,environmentalanditisqueries.achievedThebylattercombiningprovidethe
thetrustworthyinformationrequiredintheimplementationofaprotectionpolicy.
4ThisMONADS-Pistheascalapproachprogrammingimplelangmenteduagein(antheMONADSobject-orientedsystem,extensionwheretotheISOPrun-timeascal)alsosystemusedofthethe
246].[195,informationtype

IssuesGlobal7.4

213

equateAnotherformsofprobleminformationareainmanyconfinement.operatingHeresystemsSPEEDOSistheusersinabilitycantodecideprovidebetweenad-
(orequateevenforcombine)manysimpletwodifferentapplications,isapproaches.touseOnecall-outapproach,bracketwhichmethodsiscertainly(againad-po-
tentiallycombinedwithenvironmentalqueries,e.g.targetfileand/ortargetcode
module)todeterminewhetherthecallerispermittedtopassinformationtohisin-
tended(alone)totargethandlemodule.moreHowevercomplex,call-outsituations.bracketsFormayexamplenotifaprovideusersufficientwishestopowerpre-
ventsupposedaprintertoprint,modulehecannotfromsecretlyachievethisstoringsimplyacopybyofthepreventingainformationcalltothewhichprinteritis
finementmodule—assumingrestrictionsthat(usinghehisactuallycapabilitywantsortoaprintcall-outhisbracketfile.Butmethod,hecansetdependingcon-
onthesituation)suchasunsettingthepermit_oppermission(atbothprimary
andsecondarylevels).Thushecanpreventtheprintermodulefromwritingto
Thepersistentuseofdataorencryptionmakingtocallspreventtoothereavesdroppingmodulesofwhichwritecommunicationtopersistentbetweendata.mod-
ulesiscommunicatealsosimplifiedusingbytheinter-moduleuseofcallsbracketwhichmethods,fromtheforuserexample.viewpointWhentwoappearusersto
becanuseremoteacommonmethodqualifyinginvocationsmodule(howeverinwhichtheyarethecall-outimplementedbracketsinofpractice)thesenderthey
useanencryptionkeystoredinthefileofthequalifiertoencodetheparameters.
Acall-inbracketofthesamequalifierassociatedwiththereceiverusesthesame
keymessagetodecodeacrossit.theInthiscommunicationconfigurationline5the(seeactual[153]).keyisSimilarlyneversentbothexplicitlysendersasanda
usingreceiverstheofmessagesenvironmentalinainformationSPEEDOSsystemcancurrent_thread_owneruniquelyidentify,theirwhichpartnersreturnsbya
uniqueTherearesystem-wideinfactveryidentifiermany.Howaspectsthistocanbeissuesorganisedsuchasisaccessdescribedrightsinand[151].their
nelrevocation,providesanconfiningadequateinformation,armouryofsecuremechanismscommunication,tosolveetc.theseTheinsuchSPEEDOSawayker-
thatanOSdesignercan,forexample,specifysoftwarecomponentsasmodules
withinformationbracketmethodsconfinement,whichaccessperformrightsfunctionscheckinginetc.relationOftentocapabilityseveralmechanismsrevocation,
providedbytheSPEEDOSkernelareusedincombination.

UsageResourceCompositeControlling7.4.2Sofaronlyspecificaspectsoftheproblemtocontroltheresourceusagehavebeen
analysed.Thevirtualmemoryimplementationneedstoallotasuitableamount
5Thekeyitselfisstoredinthevirtualmemory.Inordertoprotectthecontentofthevirtual
memory,itispossibletoimplementaPageTableManagerforacontainerthatencryptspagesas
theyarewrittentodiscanddecryptthemagainwhentheyareloadedintomemory.Similarlythe
DSMimplementationmaytransmitthecontentofpagesinencryptedform.Theproblemofkey
storageisverysimilartothekeymanagementprobleminconventionalsystems.

214Chapter7SignificantEffectsoftheSPEEDOSKernelDesignonanOS

ofschedulermainmemoryassignstoaeachspecificprocessproportionandofmodulethethatCPUistimeactive.toeachSimilarlyprocessthethatprocessis
areadylargetorun.softwareHoweversystemitisconsistinghardtoofcontrolmanythemodulesresourceandschedulingprocesses.InparametersSPEEDOSfor,
Theschedulersproblemareinnotacertainfixedpartsystemsofthe(especiallykernelbutfreelymainframeswithprogrammablehighprocessormodules.and
dermemorytodetermineload)isthethatthecorrectoverallallocationresourcedecisions.allocationForthishastopurposebeaconsideredmedium-terminor-
schedulermaybeintroducedinaSPEEDOSsystem,iftheOSdesignerdecidesthat
thisisshort-termnecessary.schedulers.TheEspeciallymedium-termCPUandschedulermemorycoordinatesschedulingbetweenarenotthecompletelydifferent
ticularindependentapplicationofeachisotherreduced,,e.g.thisifthecanamountdecreaseofthemainCPUmemoryutilisation,availableastomoreapar-disc
accessesmayberequired.Thusforahighlyloadedsystemtheoverallworkload
needstobemanagedglobally.
TheprerequisiteisthattheindividualschedulersforCPU,mainmemoryandI/O
bandwidthareappropriatelycoordinatedbyamedium-termscheduler.Existing
mainframeoperatingsystemsincludeasimilarworkloadmanagerservice.
puters,Anexamplewhichishowevertheworkloadworksrelativelymanagementindirectlysystem.It[243]collectsintheIBMindividualmainframesched-com-
ulerminutesloadtodefineparametersaneweverysetofminuteschedulingandusesparameterstheforinformationtheprocesses.abouttheThislastfairly10
coarse-grainedinformationcollectioncanbereplacedinSPEEDOSbythemedium-
termscheduler,whichmaybemuchmoreresponsivethantheindirectimplement-
system.IBMtheination

RemarksConcluding7.5

Thekernelanddescriptionaofmatchingimportantuser-levelelementsOSofaimplementationbasicSPEEDOShasshownsystemthecomprisedflexibilityofandthe
extensibilityoftherelativelysimplekerneldescribedinchapter6.Theprotection
andstructuringmodelsusedinSPEEDOSarethefoundationofasystemwhich
combinesdeliberatelydidprotection,notspecifyflexibilityallandaspectsofextensibilitythe.envisagedTheOSdescriptionarchitecture,inthisbutchapterhigh-
lightedtopicsthatshowtheconsequencesofthekerneldesign.
Itstructureshasbeenisanmentionedessentialinvariousprerequisiteplacesforthatobtainingtheacorrectsecuremanagementsystem.ofThismoduleseems
calledparadoxical,asecurityasasmallkernel.kernelHoweverthatthefocusesSPEEDOSonkernelsecurity-relatedalonecannotmechanismsguaranteeisoftense-
curityunlesscomplementedbyaconsiderablenumberofuser-levelmoduleswhich
implementtheactualsecuritypolicy.
secureInOS,SPEEDOSbutisthenotkernelsufficientfunctionalitytoguaranteeisthebasissecurity.forThistheisimplementationintentionalandofisa

7.5RemarksConcluding

215

causedbythestrictseparationofpolicyandmechanism.Asecuritykernelthatby
itselfaimsatguaranteeingasecuresystemimplicitlycontainsaparticularsecurity
policy.Usuallyinsuchsystemsthekernelimplementsarule-basedmandatory
accesscontrolpolicy,becauseitisoftenperceivedthatthemilitaryapproachto
systemsecurityisbydefinitionappropriate.
Itisinterestingtoobservethatthechangesrequiredtothemanagementdata
structuresinthecontainersarerelativelysmallwhencomparedtothemodulesand
processesintheMONADSsystem.Theresultingkerneldesignhoweveristotally
differentandtheOSstructureismuchmoreflexible.ManyelementsoftheMON-
ADSdesigncanbecarriedovertoaSPEEDOSsystemimplementationunmodified.
SimilarlysomeelementsoftheGrasshopperdesign(suchasthestructureofthe
discdrivermodules[59]).Theothercapability-basedsystemsthatweredescribed
inchapter3hadlessinfluenceontheSPEEDOSdesign,becausetheirarchitecture
isinlargepartsincompatiblewiththedesignphilosophyoftheSPEEDOSkernel.
TheMONADSsystemreachedahighlevelofprotectionbyrelyingonauniform
modulearchitecture,protectedbycapabilitiesrepresentingsemanticaccessrights.
AddingbracketsinSPEEDOSallowsanewlevelofprotectiontobeattained.Itis
possibletoimplementstraightforwardsolutionsformanyconfinementproblems.
Theco-moduleconceptmakestheOSstructuremoreflexibleandextensible.Ap-
plicationsbenefitdirectlyfromtheseimprovements,astheymayusetheimproved
protectionmechanismsandbettersoftwarestructuringmechanismsthatreduce
thesemanticgapbetweenOSandapplications.
Securityandprotectionarepartofaproblemcomplexwithmanyfacets.Theuni-
formapproachtoprotectioninSPEEDOSdoesnotimplythattheremustbeonly
asinglelineofprotection.Bracketsinfactareanexampleofaoftheprotection
strategyknownassecurityindepth,whichiscurrentlyalsopopularinconventional
operatingsystems[290],whereseverallayersofprotectionensurethatthedam-
ageislimitedevenifoneelementofprotectioncanbecircumvented.However
protectionisanintegralpartofSPEEDOS,resultinginasimpleroverallstructure
oftheprotectionsoftware.Beingabletoconfinetheflowofinformationwithina
softwaresystemhelpsdealingwithuntrustworthysoftware.
Inmanyconventionalsystemsprotectionandsecurityareimplementedbytreat-
ingthesymptomsinsteadofthecauses.Theproliferationofprotectionmechan-
ismssuchasnetworkfirewallsandanti-virussoftwareindicatesthatthecurrent
OSarchitectureneedstobechanged.
Ifcurrentsystemstrytoaddressthis,theyoftenrelyonencryption,signatures
andcertificates,whichthemselvesbecomeaproblem.Usersneedtounderstand
theprecisemeaningofsignaturesandcertificates,otherwisetheyareluredtoa
falsesenseofsecurity.SPEEDOStriestoaddresstheproblemwithprotectionand
securityasdirectlyaspossiblethroughsupportingasoftwaresystemstructurethat
regardsprotectionasacrucialelementofthedatarepresentation,notasanadd-on
basedoneasilymisunderstoodencryptionandsigningtechniques.Thedangerof
thesetechniquesisthattheuserthinksthatthesystemissecure,becausemany
usersbelievethatencryptionisthesameassecurity.

216

Chapter

7

Significant

Effects

of

the

SPEEDOS

Kernel

Design

on

an

OS

8Chapter

217

forPrototypeArchitecturex86Intel

nelTheonagreatestconventionalremainingprocessorquestionishowarchitecture.easyitSoisfartoaveryimplementabstractthememorySPEEDOSmodelker-
thatprovidesbothsegmentationandpagingwasassumed,butmostcommercially
availableprocessorsonlysupportpaging.Thisandotheraspectsofanactualim-
plementationwhichhavesofarbeenignorednowneedtobediscussed.
ThemostimportantpartsoftheSPEEDOSkernelwereselectedforbuildinga
prototype.TheSPEEDOSkerneldesigndescribedinchapter6wasdevelopedin
parallelwiththeprototype,whichmeansthatthelattercorrespondsinpartstoan
olderkerneldesign.Thedifferencesarecomparablyminor,butinsomepartsof
theprototypetheyareclearlyvisible.
Emphasiswasplacedontheimplementationofthenewprotectionandsoft-
warestructuringmechanisms,bracketsandco-modules.Theremainingpartsof
thekernelareimplementedinafashionthatsimplifiedtheirimplementation,at
theexpenseofdeviatingfromthedescribedmodel.Thisismainlyduetothefact
thattheprototypedoesnotincludetheuser-levelpartsoftheOS,becauseoftime
constraints.Aconsequenceofthisfocusonaworkingimplementationisthatthedelegated
functionality(e.g.pagingandscheduling)wassolveddifferently.Forpagingthis
wasrelativelysimple,asthebootstraploaderpopulatestheinitialvirtualmemory
levelcontent.schedulerAdditionallytheitprototypewaswouldnecessaryhavetobeenmodifytherestrictedschedulertoa.Wsingleithoutprocesstheuser-only.
Thiswasdeemedinappropriateevenforaprototypethatservesmainlyasaproof
ofconcept.Thusasimplepriority-basedschedulerwasincludedinthekernel.

DecisionsImplementationundamentalF8.1

Selectinganappropriate,typicalhardwareplatformisprobablythemostfunda-
mentaldecisionfortheimplementationofanOSkernel.Itwasdecidedthat
thebecauseprototypeusingashouldcheap,beforpopularanoffhardware-the-shelf,“IBMarchitecturecompatible”avoidsthepersonalproblemscomputeren-,
counteredwiththecustomprocessorarchitectureintheMONADSproject.
officiallyThisimplicitlycalledIA-32determined(for32thebitIntelprocessorArchitecture)architecture.[120,The121,122,architecture123],isbuttodayis

218

Chapter8PrototypeforIntelx86Architecture

commonlyreferredtoastheIntelx86architecture.Itwasdecidedtoignorespe-
cificapplicablefeaturesasofpossiblethistootherarchitecture,processorinordertoarchitectures.maketheThisdesignmeansofthethattheprototypesegmen-as
tedvirtualmemorysupportprovidedinthex86architectureisignoreddeliberately,
becauseTheprototypesegmentationwasisnotimplementedavailablefrominthescratch,otherwithoutcurrentlybasingavailableitonanarchitectures.existing
kernel.EventhelibrariesthatfacilitatetheimplementationofanOSkernel(such
asthepropriate,OSKitas[88,their89,84]implementationprovidedbycontainsthetooUniversitymanyofassumptionsUtah)wereaboutdeemedthevirtualinap-
memoryFurthermoredesignthewhichprototypewerekernelincompatibleiswithimplementedSPEEDOSinthe.programminglanguage
C,supplementedbyasmallamountofcodeinassemblylanguage.ThelanguageC
lowwaslevelselectedofbecauseabstraction.ofitsYetthesimplicity,powerfulwhichmeansabstractionsthatitprovidedprovidesbyamorecomparablymodern
programminglanguagesinterferewiththepredictabilityofthegeneratedcode.In
aRkernelecentitisresearchvitalthat(cf.PcodeUREis[268])executedthatattheintendsrighttotimesimplifyandtheintherightimplementationcontext.of
operatingsystemsisdeliberatelyignored,asitfocusesontheconstructionofOS
kernelfamilies.design.ItTheemphasisesaimsofthePUREcodeandreuseSPEEDOSaspect,havewhichaisfewirrelevantsimilarities,forasincenewPUREOS
isstrategybasedforoneasilyaspect-orientedimplementingprogrammingfamiliesofoperatingconcepts.systems,HoweverPwhereasURESPEEDOSdescribesisa
anactualdesignofanOSthatprovidesstructuringmechanismstoitsapplications.
pletePerformanceimplementationandsizeofofthethekernelprototypeandthearenotassociatedconsideredOStobemodules.typicalforNeverthelessacom-
thecomplexityreductionofthekernelduetothedelegationofOSfunctionalityto
visible.clearlyisco-modules

ImplementationMemoryVirtual8.2

Thediscrepancybetweenthevirtualmemorymodelusedinthedescriptionofthe
SPEEDOSkernel(cf.section6.4)andthevirtualmemorysupportprovidedbythe
commerciallyavailableprocessorarchitecturesisconsiderable.
internalAssumingthatfragmentationSPEEDOSnegligible,segmentsaresegmentationreasonablycanbelargetoimplementedmaketheefficientlyeffectsus-of
ingpotentiallypaging.Itdifferingrequiresaccesssomerightstrickerytoawithsinglethesegment,pagebutaccessitisrightscertainlytorepresentpossible.the
Theplementationmoreofseveretheproblemvirtualismemorythesizeofrequirestheatpagedleast2virtual128bytesmemoryof.Avirtualrealisticmemoryim-
space,inordertosupportasufficientnumberofcontainernumbers(whichmust
beDSMisuniqueoverenvisaged,time).thenIfaprobablywide-area2256bytesnetworkofwithvirtualalargememorynumberspaceofisnodesrequiredusingto
accommodateauniquenodeidentifierinthecontainernumber.

ImplementationMemoryVirtual8.2

219

cessorSuchalargearchitecture.virtualTomemoryavoidspaceconfusingisthecurrentlydifferentnotlayerssupportedofthedirectlyvirtualbyanymemorypro-
implementation,thefollowingnotionswillbeusedconsistently:
Processorvirtualaddress(PVA):Thisisthefamiliar232or264bytepagedvir-
tualmemoryspaceprovideddirectlybytheprocessorarchitecture.
SPEEDOSsegmentedvirtualaddress(SSVA):Thisreferstothecombinationof
aingthesegmentintendedcapabilitysegment(i.e.thecapability)registerandnumbera64ofbittheoffsetsegmentwithinregisterthesegment.contain-
Rememberthatasegmentmaycoveralmostanentirecontainer.
SPEEDOSdressanypagedbyteinvirtualthehugeaddressvirtual(SPVA):memoryThisisspacea256bitmentionedaddressabove.thatItmayconsistsad-
ofthecontainernumber(192bits)andthe64bitoffsetwithinthecontainer.
Theimplementationoftheorthogonalsegmentationandpagingschemede-
scribedrequiredbelowmanagementdefinesthestepsrelationrequiredtobetweenmaintainthedifferentconsistencyvirtualoftheaddressesdifferentandlevels.the

8.2.1SegmentationinaPagedVirtualMemoryArchitecture
Thesegmentationfirststepofandthepagingvirtualistheaddresstranslationtranslationofintheasystemaddressusedprovidingbyaorthogonalprogram
(definedintermsofthePVA)intoaSSVA.Thisfirsttranslationsteptoimple-
mentsegmentationisrequired,becausethecurrentprocessorarchitecturesneither
provideameanstospecifythesegmentregisterwhichshouldbeusedforapar-
ticularreference,norsupportarbitrary-sizedmemoryobjects.Thusthesegments
mustbealignedtopageboundariesandthesizeofeachareamustberoundedup
toamultipleofthepagesize.Furthermorethesegmentregisternumbermustbe
embeddedinthePVArepresentation.
ThemoststraightforwardapproachwouldbetousethetopfewbitsofthePVA
tosegmentrepresentregistersdirectly1,thisthelimitssegmentthesizeregisterofanumbersegment.toFor512aMbytesnon-minimalorless.numberof
Anoptimalsolutionwouldbetoallowtheprogrammerofamoduletoplace
thecurrentlyaccessiblesegmentsfreelyinthePVAspace.Intheprototypeacom-
promisebetweenthesetwoextremesisimplemented,whichenforcesthatthetwo
topcontainerbits.ofThethePVfourthAcontainpossibilityatwo-bitforthisidentifieridentifierofisthereserved,currentandcode,infiletheandx86stackpro-
totypesegmentisisusedalwaysfortheplacedkernel.ataThiswell-known“convention”positionhasbythetheadvantagekernel.Thisthatthesimplifiescode
1Theleastnumberofsegmentregistersis4.Onesegmentregistereachisrequiredtoaddress
theregistercodeissegmerequirednt,theptemporarilyarameter,e.g.segmentwhenaandnewasegmentsegmentisinalltheocated.fileIfcontainerseveral.Asegmentsfurtherinsegmeeachnt
containerareusedfrequently,atleast8or16segmentregistersarerequired.

220

Chapter8PrototypeforIntelx86Architecture

coderepresentinggenerationbytheposition-independentcompiler,ascodethex86efficientlyprocessor.architecturehasdifficulties
Thekernelthenonlyneedstoknowtheplacementofeachcurrentlyaccessible
eachsegmentsegmentinrelationregisterto.theThisPVisA.ofcThisoursisenoteasilypartofachievedthebysegmentaddingacapabilityPVA,entrybuttois
sizeinsteadfieldsofspecifiedtheasasegmentfurthercapabilparameterityapplytotheequallytoload_pointertheplacementinstruction.inthePVTheA
space,asoverlappingsegmentsmustbeprevented.
aSSVThusAinandusingcombinationthenormalwiththesegmentationsegmentcapabilitytranslation,thePVA(implementedcanbeintranslatedsoftware)to
toaSPVA,asshowninFigure8.1.Notethatthesegmentcapabilityprimarily
coincidedetermineswiththetheaccesspagerightsboundaries,(AR)tothisaispage.easySincetotheimplement.segmentboundariesalways
APV

ofranslationTASSVtoAPVASSV

usingSegmentationregisterssegmentcurrentARASPV

Figure8.1:Translationofaprocessor-supportedvirtualaddresstoaSPVA
ferenceTheseparationbetweentheintotwodifferentstepsisvirtualactuallyaddresses.notThenecessary,segmentationbutemphasisesstepistheentirelydif-
independentfrompagingbecauseofproblemswiththelimitationsofthecurrently
architectures.processoravailableprototypeActuallyindoesthenotprototypesupportthetheshortnumberofpointerareasinarepresentation.segmentisInsteadreducedalltotwo.referencesThe
to“moduleothersegmentscapability”arearea,representedwhichinbythesegmentprototypestorescapabilities,bothwhichsegmentareandstoredinmodulethe
samecapabilities.size.TheBothdistinctionkindsofbetweencapabilitiesmodulearerepresentedcapabilitiesbyanddatasegmentstructurescapabilitiesofthe
isremainingimplementedcontentbyofusingacapabilitydifferentvaluesdependsforthecompletelytypeonfield.theThecapabilitymeaningtype,ofi.e.the
segmentcapabilitiesandmodulecapabilitiesdonotsharetheinterpretationof
fieldsotherthanforthecapabilitytype.
orEachcapabilities,segmentinthedistinguishedprototypebyaimplementationdata/capabilityonlyflagincontainstheeithersegmentnormalcapabilitydata.

ImplementationMemoryVirtual8.2

221

Thesegmentcapabilitytypedetermineswhetherthesegmentisdirectlyaccessible
byuser-levelcodeoraccessiblebythekernelonly.Toallowarbitrarydatastruc-
turestoberepresented,therearealwaystwosegmentsthatcorrespondtoasingle
segmentintheSPEEDOSdescription.Asaconsequenceeachco-modulehastwo
rootsegmentsandsimilarlytheparameterlistisrepresentedbytwosegments.

8.2.2ImplementingaHugePagedVirtualMemory
Allcurrentlyavailableprocessorarchitectureshavetroublesupportingtheenvis-
agedsizeofthevirtualmemory.Infactveryfewoperatingsystemshaveattempted
toimplementsuchalargevirtualmemoryspaceonoff-the-shelfhardware.
Whilesomeprocessorarchitecturessupportavirtualmemorywith64bitad-
dresses,thisbyfarisnotsufficienttoimplementthevirtualmemoryspacerequired
bySPEEDOS.Theprocessorarchitectureoftheprototypehasevenmoreseverelim-
itations,asitonlysupportsa4Gbytevirtualmemoryspace.
TheMainMemoryPageTablemaintainedbythekernel(seesection6.4.2)con-
tainsalltherequiredinformationtotranslatetheSPVAtothepageframenumber.
Theprototypeimplementsthispagetableasahashedpagetableofanappropri-
atesize,handlinghashingcollisionswithinthehashedpagetable.Theprobing
followsapseudo-randomnumbersequencegeneratedbythelinearcongruential
method(cf.[161]).Thisguaranteesthateventuallyallslotsofthehashtableare
probedwithoutcheckingaparticularslotmorethanonce,avoidingtheproblems
withclusteringthatwouldoccurifasimplerprobingsequenceisused.
Thehashedpagetableisnotdirectlyusablebytheprocessor,asitsentriesuse
SPVAsinsteadofPVAs.Theprocessorcannotdirectlyusetheglobalinformation
storedinthehashedpagetable,astheaddressformatistoolarge.ThustheTLB
misshandlerneedstocreateaTLBentryforthePVAwherethefaulthappenedto
theappropriatepageframecontainedinthehashedpagetable,i.e.usingboththe
segmentregistercontentsandthehashedpagetable.

AAPVSPVAR

agingP

&

Page#PageFrame#AR

Figure8.2:DeterminingthemainmemoryaddressandconstructingaTLBentry

anyThetimefactisthatthekeyonlytoaansmallefficientnumberofimplementation.containersandHoweversegmentssincearetheTLBaddressablecontainsat

222

Chapter8PrototypeforIntelx86Architecture

2onlychanges.localThisinformation,includesiteachmustprocessbeflushedswitchandwhenevereachtheinter-moduleaddressingcall.Inenvirofactnmeevennt
Floadingoraprocessorsnewthatsegmentdonotregisterprovidemayarequiresoftware-loadablesomeTLBentriesTLB,toanotherbedeleted.solutionhas
tobefound.TheIntelx86processorarchitectureisanexampleofsuchanarchi-
tecture,wheretheprocessordirectlyaccessesthepagetable.Howeverasoftware-
loadableTLBcanbesimulatedbyinitiallymarkingallpagesasnotpresentinthe
apageTLBmtableissusedhandlerbyintheamoreprocessor.advancedThepageprocessorfaulthandlerarchitecture)(whichupdatescorrespondsthispageto
pagetableastableinrequired.additionThetoTLBtheTLBflushoftheoperationprocessor.mentionedThisensuresabovethatneedsthetoclearcontentthisof
theTLBisundercompletecontroloftheSPEEDOSkernel.
maybeInterestinglyimplementedtheinalargesoftware-implementednumberofdifferentSPEEDOSways.TLBonThethex86implementationarchitecturein
theprototypemaintainsasinglepagetableperprocessor,whichisfullypresentin
4mainMbytesmemoryof.mainOna32memorybit.Aarchitecturemorethisadvancedisalmostimplementationnegligible,ascoulditonlyuserequiresseveral
Ifsuchseveralpagepagetablestotablesavoidarethemaintained“TLBflush”orifcostthepageassociatedtableofwithaa64processbitprocessorswitch.
memoryarchitectureisaismoretobesuitablerepresented,implementationthenprobablystrategya.Ifpooltheofkernepageslrunslockedoutofinspacemain
forthepagetablerepresentation,itmaydiscardanother,notrecentlyusedportion
ofthepagetableandreuseitforthenewentries.
kernel.TheTLBItismissresponsiblehandlerisforthepivotalimplementingelementbothinthesegmentationvirtualmemoryandpaging,supportbyhidingthe
thehugevirtualmemoryspaceofSPEEDOS.TheTLBflushoperationsareobvious
tem.performanceInaconventionalbottlenecks,OSbutthethisTLBisisnotalsoaseriousflushedatdifferenceeverytoprocessaconventionalswitch,sosys-the
onlySPEEDOSadditionaliscomparedoverheadtoisancausedout-ofby-processtheOSTLBbasedflushononanmessageinter-modulepassing,call.thenitIf
cessbecomesswitchobviousrequiredthatforthisinter-processperceivedadditionalcommunicationoverheadinanout-ofcorresponds-processtoOS.theThuspro-
inable,facttheusuallyTLBslightlyflushfrequencyfavouringofSPEEDOSSPEEDOSifaandsuitableothermoduleoperatinggranularitysystemsisisused.compar-

SynchronisationandScheduler8.3

Theschedulerimplementationintheprototypedeviatessubstantiallyfromthe
SPEEDOSkerneldesign,asmentionedintheintroductiontothischapter.Thus
itisnotconsideredaninterestingpartoftheprototype.Itimplementsastandard
2Thisdressablemayinbethenewoptimised,addressingdeletingeonlynvironment.TLBentriesHoweverthatmostrefertoprocessorsegmentsarchitecturethataredononotlongersupporad-t
flushingonlyTLBentrieswithinacertainPVArange.

8.4ImplementationofKernelInstructions

223

priority-basedschedulerwitharbitrarilymodifiableprocesspriorities,i.e.theyare
notfixedforthelifetimeoftheprocess.
Synchronisationismoreinteresting,asitisusedbythekernelandtheco-
modulesresponsiblefortheCo-moduleTable,ThreadTableandCodeTable.The
kernelimplementstwosemaphorevariants,standardcountersemaphores[60,
138]andreader/writersemaphores[46,135].Bothvariantsassociatethequeueof
waitingprocesseswiththeSPVAoftheinitialsemaphorestate(seebelow),which
maybestoredinanysegment.
Thewaitingqueuesaremanagedbytheschedulerandareheldinkernelspace.
Becausethekernelisnotpersistent,itmustbearrangedthatthestateofthevir-
tualmemoryconsistentlyreflectsthestateoftheprocessesafterareboot.The
usualatomicitypropertiesofthekernelinstructionsareusedforthispurpose.A
processthatblockedonasemaphorewillrestartthesemaphoreoperationwhenit
isresumed,i.e.itistreatedasifitneverhappened.
Ifthekernelweretoupdatethecontentofthesemaphoreinthevirtualmemory,
areflectingreboot.theThusthenumberofsemaphorewaitingcounterprocesses,isonlythisupdatedwouldasneedlongtoasbeitrolledremainsbacknon-on
negative.Thekernelusestheinformationstoredintheassociatedwaitinglist(in
listtheiskernel)deletedtoanddeterminetheprocessesthenumberintendingoftowaitingentertheprocesses.criticalAtaregionreboot,willthetrywaitingagain.
Nospecialprecautionshavebeentakentoavoidthewell-knownproblemswith
semaphoresinconjunctionwithapriority-basedscheduler.Oneoftheusualmod-
ifiedsemaphoresemantics(priorityinheritanceorpriorityceiling)couldeasilybe
implemented,butthiswasnotconsideredimportantfortheprototype.

8.4ImplementationofKernelInstructions
Theatomicityofkernelinstructionsonasingle-processorcomputerisguaranteed
incessed.SPEEDOSOnbymulti-processordisablinginterruptscomputerstherecompletelyisawhilefine-grainedakernelinstructionsynchronisationisthatpro-
kernel.implementsThesemaphorereader/writerisassociatedsemaphoreswithfortheeachSPVAofcapabilitythethatcapabilityisandaccessedthebysema-the
phoreThisstatelow-levelisstoredinthesynchronisationschedulermechanismdatastructuresusedinwithinthethekernel.implementationof
kernelisationinstructionsmechanismisdescribedbasedoninbusythewaiting,previousunlikesection.theBusywaitingscheduler-basedisacceptablesynchron-if
isthetheresourcecase,becausecontentionprocessesislowandexecutingtheondurationdifferentoftheprocessorscriticalregionrarelyisuseshort.thesameThis
capabilitiesandkernelinstructionsexecutefairlyquickly.
locksMost(circularkernelwait)instructionsiftheaccesssemaphoresmorearethanoneacquiredcapabilityinthe,which“natural”canleadorder.toIndead-the
kernelprototype,instructiondeadlocksbyareincreasingavoidedSPVbyA.sortingallsemaphorerequestsforasingle

224

Chapter8PrototypeforIntelx86Architecture

Theresemblesprogrammingmicroprogramming,stylerequiredsincefortheimplementingproblemisverykernelsimilar.instructionsIneverysomewhatkernel
requiredinstructionfortheimplementedinstructioninisSPEEDOSavailableitisandensuredconsistent,firstthatbeforethetheentireactualinformoperationation
isperformed.Becauseallinstructionsareexecutedindivisiblyandwithinterrupts
statedisabled,ofathekernelkernelinstruction.onlyneedsThetostatemaintainoftheonecurrentlystackexecutingrepresentingmoduletheisinternalleft
unchanged(buttheschedulingstatemaybemodified)ifaninstructioncannot
becompletedimmediately,e.g.ifapagefaultoccurred.Suchinstructionsare
Iteventuallygreatlysimplifiesre-executedthefromkernelthethatitbeginning,doesnotwhenhavethetofaultsupporthandlerprocessesreturns.thatare
isblockedrepresentedinthebymiddletheofvirtualakernelmemoryinstruction,contents.sinceOncethetheentiresoftwarestateofuserinfrastructureprocessesfor
thiskindofkernelinstructiondesignwasimplementedintheprototype,itbecame
mucheasiertocontinuefromthispointon.Themajorremainingdifficultieswere
thepeciallyinherentlytheinter-modulecomplicatedcall.kernelHoweverinstructions,thesesuchdifficultiesasthearenotprocessaswitchconsequenceandes-of
theinevitablekernelstructurecomplexityorofthetheatomicityinstructionsofkernelthemselves.instructions,buttheyareduetothe

ImplementationCallModule8.5

Themodulecallimplementationintheprototypefocusesontheproofofconcept
forbracketandco-modulesupport.Theotheraspectsoftheinter-modulecall
semantics(e.g.supportingconfinementbasedontheconfinementbitsinamodule
capability)areignored,butcouldbeimplementedwithoutmucheffort.
ImplementingtheindirectiontoaccessthecorrectentryintheCo-moduleTable
orCodeTableistrivial,becauseitonlyinvolvesusingthecorrectentryinoneof
thesetables.Theimplementationofbracketsismorecomplicated,asthecorrect
orderofbracketmethodinvocationmustbedeterminedandthepassingofpara-
metersandreturnvaluestothetargetmodulemustbeorganised.
Forthisreasontheprototypedoesnotimplementthebracketsequencinginthe
kernel,butitisdelegatedtoaco-moduleofthecurrentprocess,calledtheBracket
Sequencer(BS).Thisco-moduleisresponsible(incooperationwiththekernel)for
managingthestateofbracketexecution.Thekernelonlyinvokesasinglemethod
ofthisco-module,andpassesallrequiredinformationtothismethod.Thisincludes
inparticularapointertothebracketexecutionstatedatastructurecreatedbythe
BSwhentheprocessingoftheinter-modulecallwassetup.Whensettingupan
inter-modulecall,thekernelpassesthemodulecapabilitiesforthequalifierlist
modulesrepresentingcall-inandcall-outbracketstotheBS.
SincetheBSmustknowaboutallcall-relatedkernelinstructions(especiallythe
bodyandreturninstructions)relatedtoaparticularmethodinvocation,itwas
decidedthatthekernelprovidesonlyasinglesuchinstruction,calledcall_op.

ImplementationCallModule8.5

225

Thisbetweeninstructioninter-modulerequirescall,anreturnoperandandthatbodyis.ThisinterpretedallowsbytheBSexperimentationandwithdistinguishesdif-
semantics.bracketferentThekernelstillimplementstheinter-modulecallandreturnoperations,butthey
areinvokedmainlyinresponsetotheinformationreturnedbytheBS,inpartic-
ularwhetherthethetargetkernelmoduleshouldcapabilityinvokeandanotherentrymodulepointor(EP).ifitItsshouldreturnreturnvaluestotheindicatepre-
viousmodule.Allinformationrequiredtocontrolthenestingofmethodcallsin
thepresenceofbracketsispassedtothekernelinthereturnvalueoftheforced
methodcalltotheBS.Thisisthecoreofthecall_opinstruction,assketchedin
Figure8.3(ignoringthebracketstaterepresentation).Manydetailsareomitted,
becausetheywoulddistractfromtheproblemswithdelegatingbracketsequencing.

call_op(intcode,operands*o,param_list*p)
{

st;bs_opstatesetofModCapget_qualifiers(o.target,qualifiers=o.target_ep);

ifswitch(qualifiers(code)=={{}){
case0://invoketargetmethod,noqualifiers
p);code,o.target_ep,inter_module_call(o.target,break;case1://return,noqualifiers
...

}{else}st=inter_module_call(bracket_sequencer,code,o,qualifiers,p);CALL_OP,
{(st.code)switchcase0://invokebracketmethodortarget
p);st.ep,inter_module_call(st.modcap,break;case1://returnfromaqualifiedmethodorbracket
inter_module_return(st.ret_val);break;...

}

}

}Figure8.3:Partialpseudocodeimplementationforcall_opinstruction

trustedTheprototypeco-moduleofdelegateseachtheprocess.Whileresponsibilitythisforseemscorrecttobeverybracketattractivesequencingandtowasa

226

Chapter8PrototypeforIntelx86Architecture

consideredforthefinaldefinitionofthekernelinchapter6,ithasalsodisadvant-
ages.Theimplementationisveryhardtounderstand,becausethedatastructures
topasstheoperandstotheBSareactuallydefinedmainly(butnotexclusively)
bytheBS.Thisrequiresrelativelycomplicateddatastructuresthatareinpart
definedbythekernel(linkage)andpartiallybytheBS(e.g.positioninbracket
list).Howeveritviolatestheinformation-hidingprincipletocreatesuchdual-use
datastructures.Whileitwouldbepossibletoseparatebothaspects,thiswould
requireduplicatingsomeoftheinformationbetweenthetworesultingdatastruc-
tures.Thesedifficultieswiththedesignoftheappropriatedatastructuresarea
stronghintthatthedelegationofbracketsequencingisactuallyinconflictwiththe
designphilosophyofSPEEDOS,asdescribedinsection6.1.
Aparticularlysevereconsequenceofthedelegationofbracketsequencingto
aco-moduleofthecurrentprocessisthatitinterfereswithinterrupthandling,
inparticularwithpagefaulthandling.Asaresulttheprototypehastoignore
thepotentialpresenceofbracketsforallforcedmethodcallsandinsteaddirectly
invokesthetargetmethod.ThisespeciallyappliesforbracketsoftheBS.
Thereisaninherentdangerofcreatingendlessloopsswitchingbackandforth
betweenthekernelandtheBS.Ignoringbracketshoweverweakenssecurityand
makestheimplementationofaccountingandchargingmorecomplicated,asit
forcesthebracketcodetobeincludedintheimplementationofthemodulewhichis
theforcedmethodcalltarget.ThisviolatestheSPEEDOSkerneldesignphilosophy.
Another,lesssevereproblemisthatthekernelwouldnotknowanythingabout
theexistenceandmeaningofbrackets.Thiscreatesaproblemwiththeimple-
mentationoftheenvironmentalqueriesthatreturninformationabouttheclient
andtargetmoduleforabracket.Thiscanbesolvedeither
a)bydelegatingtheseenvironmentalqueriestotheBSor
b)byreturningtherequiredinformationfromtheBStothekernelforevery
instruction.call_opCase(a)ignoresthefactthataccesstosuchenvironmentalqueriescanbecon-
trolledthroughtheThreadSecurityRegisterandthatinter-modulecallsaresubject
tootherconfinementrestrictions.Eitherthekernelwouldneedtoperformtheas-
sociatedforcedmethodcallsinthecontextofakernelimplementationofthese
environmentalqueriesorthequalifiermoduleswouldneedaccesstoamodule
capabilityfortheBS,whichisnotacceptable.Whicheverimplementationvariant
isselected,queryinginformationabouttheclientortargetmoduleismuchmore
expensivethantheotherenvironmentalqueries.
Theimplementationofcase(b)increasestheamountofinformationthathas
tobereturnedfromeachinvocationoftheBS.Theamountofinformationthat
canbepassedefficientlytothekernelislimitedbythenumberofprocessorre-
gisters,whichisverylimitedinthecaseofprototype,astheIntelx86architecture
providesonly7usablegeneral-purposeprocessorregisters.Thenumberofregisters
availableintheprototypesufficesbarelyforanimplementationthatdoesnotpass

Summary8.6

227

informationabouttheclientandtargetmodules.Thisimplementationpossibility
problems.efficiencycausesalsoparedThetohandleimplementationnon-bracketedofcall_opmethodiscalls.relativelyItisconvoluted,anticipatedsincethatitthemustbeimplement-pre-
ationofthethreecoreinter-moduleoperations(call,return,body)describedin
BS.chapter6FurthermoreisactuallythelesseffortimplementationandeasierintoFigure8.3understanddoesnotthanworkthecorrectlydelegationiftoquali-the
fierproblemslistmodulescausedarebytheaddedordelegationremovedofwhilebrackettheexecutionbracketedindicatemoduleisthatitactive.isnotAllad-the
visabletodelegatethebracketexecutiontouser-levelcodeinaproduction-quality
Theimplementationprototypeoftheimplementationkerneldesign.onlyservesasaproofofconceptinthisareaand
wasdeliberatelyoptimisedforexperimentationwithdifferentinter-modulecall
andprocessbracketpotentiallysemantics.definesInaitsownproduction-qualitymodulecallandkernelitbracketisnotsemanticsnecessarythroughthateachthe
provisionenvisagedofaBS.implementationAssuchoftheaSPEEDOSprototypekernel.designisdifferentinthiscasefromthe

Summary8.6

Inthischaptersomeimplementationaspectsoftheprototypeimplementationhave
beendescribed.TheSPEEDOSkerneldescriptioninchapter6basedonanabstract
memorymodelthattodaycreatessomedifficultytoimplementitonthemajority
ofcommerciallyavailableprocessorarchitectures.Theresultingvirtualmemory
implementationisslightlymorecomplicatedthantheimplementationformany
conventionaloperatingsystems,whichprovidesisolatedvirtualmemoryforeach
processinthesystem.HoweverSPEEDOSachievesmoreflexibility,extensibility
andprotectionbymakingprocessesandmodulesorthogonalconcepts,following
thein-processmodel.Passive,separatelyprotectedmodulesareabetterbasisfor
sharinginformation,asthesemanticinterfacetoamodulesupportsbothmore
fine-grainedprotectionandtheinformation-hidingprinciple.
ThebenefitsofthememorymodelinSPEEDOSoutweightheslightlymoreex-
pensiveTLBmisshandlingcosts.Themajorityoftheincreasedcostisduetothe
supportforaverylargevirtualmemoryspace.InfacttheSPEEDOSmemorymodel
canbeimplementedefficientlyonprocessorarchitecturesthatdonotprovideseg-
mentation,evenifthedescriptioninchapter6assumedamemorymodelproviding
paging.andsegmentationorthogonalWhiletheprototypedesignprovedtobenotcompletelyidealfortheaimsof
identifySPEEDOS,theweaknessesproblemsofthehelpedearlySPEEDOSidentifyingkernelbetterdesignsolutions.byIttryingwastopossibleimplementto
averyambitiousandinitiallyvaguespecification,whichfocusedonthephilosophy
“delegateeverythingtotheappropriateuser-levelentitywherepossible”.Theex-
perienceswiththisattemptwerevaluableinchapter6,whichreplacedthedesign

228

Chapter8PrototypeforIntelx86Architecture

Thephilosophypurpose“whereofthepossible”prototypeusedistointheprovideprototypetheproofwithof“whereconceptandreasonable”.tocreatethe
opportunitytoexperimentwithdifferentdesignsforthenewbracketandcompos-
itekernel.moduleThekernelconcepts.designThereflectsprototypethehelpedexperienceswiththemadedesignwithofthethefinalprototype,SPEEDOSthus
thetiallyfromimplementationthekerneldesigncharacteristicsdescribedoftheinchapterprototype6.deviatesinsomeareassubstan-
Intheprototypeseveralelementsofthekernelspecificationweredeliberately
difficultexcludedto(e.g.implement,thebutimplementationwouldhaveoftheintroducedconfinementevenmorebits).Theycomplexityareininfactalreadynot
non-trivialcode.Howevertheomittedaspectscanbeeasilyaddedlater,astheir
Thecomplexityexperienceswhenwithviewedtheinisolationprototypeisnotdescribedveryinsevere.thischapterarehoweverexpec-
tedkernel.tohelpSomewiththedifficultiescanimplementationbeavoidedofabyselectingproduction-qualityamoreversionmodernoftheprocessorSPEEDOSar-
chitecturethaninthisthesis,asthesegenerallysupportasoftware-loadableTLB
thisdirectly,chapteraseliminatingitisspecificmuchtotheimplementationIntelx86processorcomplexitythatarchitecture.wasnotmentionedin

9Chapter

Conclusion

229

IfIstandinghaveseenonathelittleshouldersfurtherofitisGiants.by
(SirIsaacNewton,1643–1727)
theThispreviouschapterchapters.concludesAtheshortmainoverviewpartofofthethethesis.significantItnewsummarisescontributionstheresultsinthisof
thesistothestateoftheartinoperatingsystemdesignfollows.Finallythischapter
suggestsSPEEDOSpossiblekernelfuturedesign.researchdirectionswhichareenabledbytheresultsofthe

Summary9.1Inchapter3,theanalysisofexistingoperatingsystemandkerneldesignsun-
coveredthedeficienciesofcurrentdesignsinrespecttotheOSstructureandthe
versatilityoftheprotectionsystem.Basedonthisresultitwasattemptedtosolve
boththeprotectionandstructuringproblems.
ThedesignoftheSPEEDOSkernelincludesthedefinitionofanewOSkernel
structureandthefunctionalityofessentialOSmodules.Itsdesignaddressesthe
protectionandstructuringproblemsofotherkernelandOSdesigns.Particularem-
phasishasbeenplacedonuniformity,protection,extensibilityandflexibility.This
byitselfisnotsubstantiallydifferentfromtheaimsofanumberofotherkernels,
howevertheapproachchoseninSPEEDOSleadstoaratherdifferentdesignthan
systems.otherinManyOSdesignershavemoreorlessexplicitlyusedthequote“Makeeverything
asarationsimpleasbetweenpossible,policybutandnomechanismsimpler”as(attributedtheirtodesignAlbertphilosophyEinstein),andandtooktheoversep-
toomanydesigndecisionsfromotheroperatingsystemwithoutsufficientchecking
foralternatives.Asaconsequencetheyoftenignoredthesoftwarestructuringand
protectionissuesandarrivedatadesignthatissimple,butdidnotaddressthe
problems.engineeringsoftwareTreatingmodulesandprocessesasorthogonal(aconceptthatisalsopresentin
theMONADSandGrasshoppersystems)isthebasisfordevelopinganewkernel
architecture.Thenewpossibilityforprotectingmodulesbyprogrammableaccess

230

Conclusion9Chapter

checksintheformofbracketsallowsnon-trivialsecuritypoliciestobeimplemented
withoutchangingthedutyoftheOSkernel.AkeyelementofSPEEDOSisthatit
strictlyadherestothein-processmodelandthatitenforcestheinformation-hiding
principlebynotallowingdirectaccesstothedataofanothermodule.
Confiningtheflowofinformationiseasiertoachievewhenfollowingthein-
processmodelthaninthemicrokernelapproach,whichhasmanystructuringand
protectionproblemsbecauseitdoesnotattempttoaddresstheseissuesdirectly.
Thecompositemodulestructuresupportedbythekernelprovidestheopportun-
itytoradicallychangethestructureoftheOS,delegatingmanyaspectsoftheOS
functionalitytoco-modulesoftheaffectedapplicationmodules.Ofcoursethere
isOSfunctionalitythatmustbeimplementedasseparate,centralmodulesina
SPEEDOSsystem.Thesemodulesrepresentthecoreresourcemanagementfunc-
tionality,whichbydefinitionmusthaveglobalknowledgeandthusshouldnotbe
implementedbydecentralco-modules,associatedwiththeapplicationmodules.
TheSPEEDOSdesignsupportstheseparationbetweenpolicy(implementedby
co-modules)andmechanism(implementedbythekernel),whichaddressesthe
criticismofoperatingsystemstructureformulatedbyWulfetal.in[306].While
manyotherkerneldesigns(especiallymicrokernels)alsoattempttoaddressthis
criticism,theyfailinpracticeduetosoftwarestructuringandprotectionproblems.
Manyoperatingsystems(includingevenmanycapability-basedoperatingsys-
tems)donotprovideasuitable,enforceablemoduleconceptatthekernellevel,
whichlimitstheirsecurity.Ifthemoduleconceptmustbeimplementedwithuser-
levelcode,itisinherentlylesssecure,becausethereismoresoftwareinvolved
thanwithakernelimplementation.Thisdoesnotnecessarilymeanthatallusers
cantrusttheimplementationofthemoduleconcept,especiallyitsprotectionand
confinementaspect.Mistrustisnotasuitablebasisforasecuresystemdesign.
Thecleanseparationbetweentheimplementationofmechanismsandpolicies
forbothprotectionandOSstructuringresultsinaveryflexibleandextensibleOS
design.Itispossibletoimplementalargevarietyofoperatingsystemdesignsbased
ontheSPEEDOSkernel.Itisnotconsideredadvisabletoimplementconventional
OSdesignsusingthedescribedkernel,asthiswouldignoremostimprovementsfor
protectionofindividualmodules.Theincreasedoverheadwouldnotwarrantthe
smallprotectionbenefitsforsuchadesign.
Protectionandsecuritycertainlydonotcomeforfree,butinthecontextofa
persistentsystemthereducedeffortduetoeliminatingfrequentcostlyoperations
suchasprocesscreationcanoffsetthecostofasophisticatedprotectionsystem
implementation.Thebettersupportforsoftwareengineeringconceptssuchas
usingoff-the-shelfOSandapplicationcomponentsprovidesfurtherbenefits.
ThetransitionfromconventionalsystemstoSPEEDOSdoesnothavetobean
abruptswitchover.Itispossibletoreusecodefromapplicationsimplementedfor
conventionalsystems,simulatingtheirfilesystemandOSsemanticsusingcode
andfilemodules.PortingexistingoperatingsystemssuchasUNIXtotheSPEEDOS
kernelisnotenvisaged,butwouldbepossible.TheresultingOShoweverwould
notusemostoftheimprovementsprovidedbySPEEDOS.

ContributionsNew9.2

231

ContributionsNew9.2Themostimportantnewcontributionsinthisthesistotheresearchonprotection
andstructuringofoperatingsystemsare:
1)Thesupportforbracketinggreatlyenhancestheflexibilityandextensibilityof
theprotectionsystem.Bracketsarefreelyprogrammableandmaybedynam-
icallyassociatedwithmoduleswithoutmodifyingcodeandwithoutrecom-
pilation.Thispromotescodereuseandswiftreactiontosecuritybreaches.
2)Compositemodulesallowthestraightforwardrepresentationofapplication-
specificpolicies.Thisallowsapplication-specificknowledgeandpropertiesto
beexploited,bytailoringdatastructuresandalgorithmstowardstherequire-
mentsofanapplication.Thecomplexityofthekernelisreducedgreatlyby
delegatingmanyfunctionstoco-modulesassociatedwithanapplication.
TheimplementationofthesemechanismsinSPEEDOS,whichfollowsthein-
processmodel,hasfar-reachingconsequencesfortheentiresoftwaresystem,con-
sistingofthekernel,operatingsystemmodulesandapplications:
1)Fine-grainedandfreelyprogrammableprotectionbasedonbracketsallows
torepresentarbitraryrule-basedaccesscontrolpolicies,whicharenotsup-
portedbymostcurrentoperatingsystems.Neithertheclientmodulenorthe
targetmoduleknowsabouttheexistenceofbracketmethods.
2)Solvingmanyconfinementproblemsispossiblebycontrollingtheflowofin-
formationbetweenapplicationmodulesusingappropriateprotectionsettings
forthesegmentsthattransferinformationorbyprovidingcall-outbrackets.
3)Monitoringwhichusersaccessaparticularmoduleispossiblethroughquali-
fyingmodules,becausethekernelprovidestrustworthyidentification.Thisis
noteasilyachievableinamicrokernel-baseddesign.
4)Separationbetweenmechanismandpolicyispartofthekerneldesign.The
kerneldoesnotencouragetheuseofparticularsecurityorresourceallocation
policies.AsingleSPEEDOSsystemmaybepartitionedintoseveralenviron-
policies.differentprovidewhichments,5)Theperformanceoftheentiresystemmaybeimprovedbymakinguseof
application-specificknowledgeinthedecentralpolicyimplementations,com-
paredwithmonolithickernelsormicrokernelswhichgenerallysupportonly
implementations.policycentral6)Thekernelprovidesonlyasmallnumberofsecurity-relatedmechanisms,re-
ducingitscodesizeandcomplexity.Thisisessentialinthecontextofsecure
systems,ascomplexkernelsareinherentlyuntrustworthy.Thekernelismore
complexthansimplemicrokernels,butitprovidessuperiorsecurityconcepts
andimprovedefficiency(byavoidingunnecessarythreadswitches).

232

ResearchutureF9.3Directions

Conclusion9Chapter

Theentireareaofthedesignandimplementationofoperatingsystemshasattrac-
tedestingaproblemsconsiderableinthisattentionfieldinhavethebeenpast.solvedHoweverthisadequatelydoes.notEspeciallymeanthattheallefficientinter-
implementationofpersistentoperatingsystemsstillposesdifficulties.Supporting
alarge,uniformvirtualmemoryistodaymuchharderthannecessaryandasa
consequencelessefficientthanitcouldbe.
Providingappropriatesoftwarestructuringsupportforapplicationsoftwaresys-
temseitheroalsontheneedsapplimorecationresearch.developmentSofarortheOSfocusofdevelopment,manybutresearchlittleprojectsprogresswashas
beenmadeinprovidingappropriateOSstructuresfortoday’sapplications.This
thesistions.Itproposedneedstobesomere-evaluatedelementsofwhichanOSfurtherthatisdemandsclosertothewouldbedemandsworthofincludingapplica-
intheSPEEDOSdesign,e.g.bymakingcompositemodulesevenmoreflexible.
Anotherareaisthesupportforworld-widedistributedsystems.Implement-
ingsolutionsdistributedforDSMsharedmemoryimplementationsonsuchthataworklargewellscaleinarequireslocal-areareconsideringnetwork.Itmanyis
likelyproachesthatthisisdifferentnotpossible,processorsincearchitecturesheterogeneousneedtosystemscooperate.requireInseveralcurrentcopiDSMesap-of
theimplementation,eachcorrespondingtoaparticularprocessorarchitecture.
Moreresearchisalsoneededtoexploretherelationshipbetweengraphicaluser
interfacesandpersistentsystems.Itisnotyetclearwhatconsequencestheintro-
ductionofpersistentsystemsshouldhaveonthegraphicalinterfacestocomputers.
FinallytheimplementationoftheSPEEDOSkernelonpopular64bitprocessor
eliminatearchitecturessomesuchofastheAMD’s64implementationbitextensionproblemstoofthePtheentiumcurrentarchitectureprototype.mayalso
Thesefutureresearchdirectionsaredescribedbrieflyinthefollowingsections.

ArchitecturesProcessortheImproving9.3.1ThecurrentlyavailableprocessorarchitecturesprovideveryfewTLBentries,com-
paredwithcurrentmainmemoryworkingsetsizes.Thisdecreasestheefficiency
ofming,aexecutingprocessasingleswitchprocess.usuallyInreaquirestheconventionalTLBtoOSbethatflushed,supportsbecausemultiprogram-processes
areisolatedbyseparatingtheirvirtualmemory.
temsInSPEEDOS(SASOS),thiswhichTLBcanflushbewouldclassifiednotasbeanecessary,Single-Address-SpaceasallprocessesOperatingexecuteSys-in
asinglevirtualmemory.Howeverthisdoesnotnecessarilyimproveefficiency,as
theseveralTLBofprocesses.currentTheprocessorsizeoftheTLBarchitectureswouldistooneedtosmallbetoholdincreased.theworkingsetof
techniquesBecausethetosizeextendofatheTLBsizeisoflimitedthebyTLBcurrentshouldbesemiconductorexploited,e.g.technologyimplementing,other

F9.3DirectionsResearchuture

233

severaleffectivelyTLBs,increaseswhichthearesizeassociatedofthewithTLB,themosteliminatingfrequentlyefficiencyusedlossesprocesses.duetoThisTLB
datamissthathandling.oftenneedsDiscardingtobetheTLBreconstructedcontextwhenonatheprocessprocessswitchcontinuesdestroysexecution.valuable
dowsAincolleaguetheSPARCsuggestedprocessoraTLBtorepresentmanagementmultipleapproachMMUsimilarcontextstothe[296].registerOtherwin-
TLBstructuresthatextendtheeffectivesizeoftheTLBareofcoursealsopossible.
Thisother,couldmoreprovideconventionalperformanceOSdesigns.improvementsforboththeSPEEDOSkerneland

9.3.2FurtherModuleStructuringPossibilities
Sostoredfarallinasegmentssinglecodethatandbelongfileeithercontainerto.theThiscodeincludesandfilealldataofco-modulesamodule(evenmustthosebe
thatdonotsharetheprivatedataofanotherco-module),forcingtheirprivatedata
tostoredbeonstoredainsingleadisc,singlethisfilelimitscontainerdata.placement.Becauseaparticularcontainerisusually
Inprivatesomedataofsituationsdifferentitmayco-modulesbedesirableofatocompositeseparatemoduletheintorepresentationseveralofcontain-the
ers.Thiswouldallowplacingthedataondifferentdiscs(orevendifferentnodes),
isticsprovidingofaevencompositemoremodule.controlovertherepresentationandperformancecharacter-
eralItmightcontainers,beevene.g.topossiblepartitiontotheseparateactualthedataprivatedatarepresentedofanbyaapplicationdatabaseintomodulesev-
intopointersdatathenrecordhaveandtobeindexabletocrosscontainers.theHoweverboundariesthatofcertaincreatesthecontainers.problemForthisthat
isreasonattractivesuchanandappshouldroachbewaspursuednotattemptedfurther.inSPEEDOS,butneverthelesstheidea

SystemsHeterogeneous9.3.3Thestructureofmodulescanbeeasilyextendedtosupportheterogeneoussystems,
i.e.differentprocessorarchitectures.Assumingthatthedatarepresentationisleft
thefileunchanged,containercompletelymustbecompatiprovided.bleTheimplementationsefficiencylossthatduecantosharethetheconversioncontentintoof
acommondataformatshouldbenegligible,becausethemaindifferencebetween
currentThereforeprocessorthemainarchitecturemodificationistherequiredendiannessisoftotheprovidedataawords.codemodulewhich
largeimplementsnumbertheofmoduleprocessorinterfacearchitecturesonallandprocessorarchitecturearchitectures.variants,Becausetechniquestherearesucha
asjust-in-timecompilationwillcertainlyhelpmakingamoduleimplementation
feasible.Itispossibletousesuchanenhancedmodulerepresentationtransparently
architectures.processordifferenton

234

Conclusion9Chapter

9.3.4UserInterfacesforPersistentSystems
Itusedisnotintraditional,immediatelyclearnon-persistentwhethertheapplicationsuserinterfacearesuitableconventionsforthatpersistentarecurrentlysystems.
Themayreasongenerallyisthatassumethethatapplicationeverythingstructurestoredisinachangedmodulebecauseisthepersistent,programmerwithout
effort.programmingfurtherWhileanumberofprogramminglanguagessupportpersistentprogramming,it
hasbasisnotforbeenuserstudiedinterfacesinthatdetailarehoweasierthetoimprovedusethanthesoftwarecommonstructureusercaninterfaceprovidecon-the
beceptskeptinpersistentconventionalintoafilesystemsthatrepresentation.needtoconvertthedataelementsthatshould
ingManypersistentproblemsmodules,withwhichincompatibleencapsulatefileformatstheetc.privatecoulddatabewitheliminatedanabstractbyprovid-inter-
face.Theabstractinterfacecanhidemanyimplementationdetails.

9.3.5Implementationon64bitProcessorArchitectures
The32bitprocessorvirtualaddressspaceprovidedbytheIA-32architectureistoo
smallforcurrentapplicationsthatneedtohandlelargeamountsofdata.Recently
AMDhaspublishedanextensiontotheIA-32architecture,calledAMD64[6,7,8,
9,10],whichextendsthebasicprocessorarchitectureto64bitwordandaddress
size.Intelhassubsequentlyadoptedtheessentialpartsofthisspecificationinits
processors.currentIn64bit-modetheseprocessorssupportonlypaging,usinga4-levelpagetable
(inprinciplealinearpagetablewiththreedirectorylevels).Themaximumsize
ofthepagetableisapproximately512Gbyte,whichrulesoutkeepingitentirely
inmainmemory(incontrasttothe4MbytepagetablerequiredfortheIA-32
architecture).HowevertheSPEEDOSkernelusestheprocessor-supportedpage
tableonlyasameanstoimplementasoftware-loadableTLB.Onlyasubsetofthe
pagetableisrequired.Appropriatediscardstrategiesforentriesinthisunusual
TLBarchitecturehavetobedevelopedthatlimitthemainmemoryconsumptionof
thevirtualmemorymanagementfunctionsinthekernel.
Additionallyitwouldbeinterestingtoanalysetherelativeperformance,com-
paredwithother64bitprocessorarchitectures,suchasIntelItanium[117,118,
119],SunSPARC[297]andApple/IBM/MotorolaPowerPC[262,263,264].

AAppendix

ReferenceInstructionernelK

235

Indescribed.chapter6Thisthechapterkernel-supportedcontainsadatashortstructuresinformalanddescriptionkernelofeachinstructionskernelhaveinstruc-been
operands.itsandtiondoesItisnotassumedimplementinthemodulekernelcapabilityinstructionregisters,descriptioni.e.inmodulethischaptercapabilitiesthatarethealwayskernel
operands.memorybyreferencedwithTheaparameterinstructionslistare(whichwritteninacorrespondsnotationtothesimilarinputtofunctionoperands)andprototypesareturninC,valuei.e.
(whichoftencorrespondstotheoutputoperand).
Thefollowingtypesareusedforparametersandreturnvalues:
ref_t:ment,thei.e.afullcombinationsegmentedofasegmentaddressofregisteramemorynumberoperand,andoffsetwithinaseg-
container_id:auniquecontainernumber(192bits),
unique_idCo-module:theTable,combinationCodeTofableaorcontainerThreadTable,numberi.e.andaan“module”indexintoidentifiereither,andthe
bitlist:afixed-sizebitsetwhichrepresentsrights.

QueriesEnvironmental.1A

theTherearecurrentlyalargeexecutingnumberofmoduleenvironmentaland/orthread.queriesThesewhicharereturndescribedininformationthissectionabout
Thegroupedbyfollowingthetypeofinstructionsinformationreturnthewhichtheyuniquereturn.moduleidentifierofthecurrent
thefilecallingmodule,codethecurrentmodule,codethetargetmodule,filethemodulecurrentandthread,targetthecodecallingmodulefilerespect-module,
ively.Thereturnedmoduleidentifierdoesnotincludethemodulecapabilitytype.
Howeverinstruction,thee.g.typethecanbecalling_codeunambiguouslyinstructionderivedreturnsfromathecodemoduleenvironmentalidentifierquery.

unique_idunique_idcurrent_codecurrent_file()()

236

AppendixAKernelInstructionReference

()current_threadunique_idunique_idunique_idcalling_codecalling_file()()
unique_idunique_idtarget_filetarget_code()()
Eachoftheenvironmentalqueriesabovereturnsacontainernumberandthe
contentoftheindexfieldinthemodulecapability.Inordertoobtaintheownerof
thesecontainers,thefollowingsetofenvironmentalqueriescanbeused:
container_idcontainer_idcurrent_file_ownercurrent_code_owner()()
container_idcontainer_idcalling_file_ownercurrent_thread_owner()()
container_idcontainer_idtarget_file_ownercalling_code_owner()()
()target_code_ownercontainer_idTheentrypointnumberofthecurrentmodule,thecallingmoduleandthetarget
modulecanberetrievedwiththefollowingenvironmentalqueryinstructions:
intintcalling_epcurrent_ep()()
()target_epintIfanenvironmentalqueryinstructionisnotapplicableinthecurrentcontext
(e.g.target_episusedoutsideabracketmethod)itreturns0.Thesamevalue
isreturnedifanenvironmentalqueryisdisabledviatheThreadSecurityRegister.

RegisterSecurityThread.2ATheThreadSecurityRegistercontainsthecurrentstateoftheconfinementand
fromenvironmenttheThreadrights.SecurityTheRegisterrefine_tsr.ThenewinstructionstateofcanthebeTSRusedisthetoremoveintersectionrightsof
thecurrentsetofrightsandthespecifiedsetofrights.
confinement_environment)(bitlistrefine_tsrbequeriedAdditionally(whichtherecouldisanbealsoinstructioninterpretedwhichasallowsantheenvironmentalcurrentstatequery):oftheTSRto
()query_tsrbitlistThetwoinstructionsformodifyingandqueryingthestateoftheTSRviolatethe
informationhidingprinciple,sincetheirusergenerallydoesnotneedtoknowor
aremanipulatemeantastheaentirelow-levelstateofmechanismtheTSRforbutonlyaimplementingspecificaright.setofThesefunctionsinstructionsatthe
programminglanguagelevel,whicheachgivesonlyaccesstoasingleright.They
arekernelnottoprotectimplementedtheTSRasasaseparatewhole.kernelinstructionssinceitissufficientforthe

SegmentManaging.3ACapabilities

CapabilitiesSegmentManaging.3A

237

Segmentcapabilitiescanbeloadedwiththeload_pointerinstruction.Itre-
quiresspecifyingatargetsegmentregisternumber(indst_segreg)andasource
pointer(throughamemoryoperandinsrc_pointer.
Similarlyapointercanbestoredwiththestore_pointerinstruction,which
requiresspecifyingatargetpointer(throughamemoryoperandindst_pointer)
andasourcesegmentregisternumber(insrc_segreg).
Segmentcapabilitiescanbealsostoredtothedataareaofasegmentusing
store_pointer,whichallowsthecontentofasegmentcapabilitytobeinspec-
ted.Suchsegmentcapabilitiescannotbeloadedintoasegmentregisterusingthe
instruction.load_pointerload_pointerstore_pointer(int(ref_tdst_segreg,dst_pointer,ref_tintsrc_pointer)src_segreg)
Creationofsegmentcapabilitiesisaprotectedkernelinstruction.Itsetsupa
segmentcapabilityforasegmentstartingatoffset_in_containerwiththe
lengthsofthedata,pointerandmodulecapabilityareasasspecifiedintheoper-
andsdata_length,pointer_lengthandmodcap_length.Theaccessrights
ofthesegmentaresettoaccess_rights.Finallythesegmentregisterspecified
bydst_segregisloadedwiththesegmentcapability.Thekernelcapabilityac-
cessiblethroughthememoryoperandkernel_capisusedtocheckwhetherthis
kernelinstructionmaybeusedatall.
create_segment(intintdst_segreg,data_length,intintpointer_length,offset_in_container,
access_rights,bitlistmodcap_length,intkernel_cap)ref_tDevicecapabilities(whichareaspecialkindofsegmentcapabilityoftenusedby
devicedrivers)canbeloadedtoaspecifiedsegmentregister(indst_segreg)by
specifyingthememoryoperandsrc_devcap,whichmustrefertoavaliddevice
capabilityinthemodulecapabilityarea.
Devicecapabilitiesmaynotbestoredtopointers,sincetheydonotrefertoseg-
mentswithinacontainer(whichispartofthevirtualmemory)buttoanI/Oarea
andenabletheholdertocontrolaparticularhardwaredevice.Onlydevicecap-
abilitieswhichcontaintheidentifierofthecurrentnodeinthemoduleidentifier
fieldofthedevicecapabilitycanbeloadedintoasegmentregister.Thisprevents
accidentaluseofdevicecapabilitiescreatedforanothernode.
src_devcap)ref_tdst_segreg,(intload_devcapSegmentcapabilitiesareneveraccessibledirectlybyusercodewithoutusingthe
kernel.Thisallowsthekerneltouseadifferentinternalrepresentationofsegment
capabilitiesfromtheexternallyvisiblerepresentation,whichisusedforexample
wheninspectingasegmentcapability.

238

AppendixAKernelInstructionReference

CapabilitiesModuleManaging.4AtionallyModulebecapabilitiesrefinedbycanbereducingcopiedthefromincludedrightssrc_modcapaccordingtotodst_modcapthemetarights(andop-,
confinement_environmentandaccess_rightsoperands)byusingthein-
detailstructioninsectioncopy_modcap6.8.1.2..AThemodulecompletecapabilitiessemanticscanofusuallythisbeinstructioninspectedisdescribed(subjecttoin
itsmetarights)bystoringittothedataareaofasegment.Suchmodulecapabilities
cannotbeusedasthetargetofaninter-modulecallorlibrarycall.
copy_modcap(ref_tbitlistdst_modcap,metarights,ref_tbitlistsrc_modcap,confinement_environment,
access_rights)bitlistThecreate_modcapcreationof,whichmodulewritescapabilitiestheisresultingpossiblemodulewiththecapabilityprotectedtotheinstructionmemory
pletelyoperandbythedst_modcapmodule_id.,Thetype,contentofmetarightsthe,modulecapabilityisconfinement_environmentspecifiedcom-
andaccess_rights.Thekernelcapabilityaccessiblethroughthememoryoper-
andkernel_capisusedtocheckwhetherthisinstructionmaybeusedatall.
create_modcapint(ref_ttype,dst_modcap,bitlistunique_idmetarights,module_id,
confinement_environment,bitlistkernel_cap)ref_taccess_rights,bitlistkernel.ModuleThisallowscapabilitiesthearekernelnevertouseaccessibleadifferentdirectlybyinternalusercoderepresentationwithoutofusingmodulethe
capabilitiesfromtheexternallyvisiblerepresentation,whichisusedforexample
wheninspectingamodulecapability.

A.5MethodInvocationandReturn
Theinvoked.Theinter_module_calltargetmoduleinstructioncapabilityisallowsspecifiedamethodinoftarget_mcanotherandmodulethetoentrybe
pointnumberidentifyingthemethodisspecifiedintarget_ep.Asegmentinthe
processcontainerofthecurrentthreadcanbepassedbyspecifyingthesegment
passedregistertothenumbercalledinmodule.param_segregThe.returnedAdditionallyvaluetheindicatescurrenttheregistersegmentcontentsregisterare
numberthroughwhichthereturnvaluesegmentcanbeaccessed.
intinter_module_call(ref_ttarget_mc,inttarget_ep,
param_segreg)intousmethodCorrespondinglyinthethecallchain,passinginter_module_returnareturnvalueinstructionsegmentreturnsbytospecifyingtheprevi-the

ManagementThread.6A

239

segmentregisternumberinreturn_segreg.Additionallythecurrentregister
contentsarereturnedtothecallingmodule.
return_segreg)(intinter_module_returnmethodTheofbodythetargetinstructionmethodisusedoriniftherebracketarenomethods.moreItbracketsinvokesittheinvokesnextthebrackettar-
getmethod.Specialisedbracketmethodscanusetheparam_segregoperand
toreturnedspecifytoaaccessdifferentthereturnparametervaluesegmentsegment.and/orForusethegeneralisedsegmentbracketsregisterthesenumberoper-
andsreturnarevalueignoredsegmentscompletelycan,bei.e.inspected.neitherTheparameterrulesforsegmentsbracketcanmethodbespecifiedinvocationnor
6.8.2.sectionindescribedareparam_segreg)(intbodyintThelibrary_callinstructionisverysimilartotheinter_module_call
currentinstruction,filebutcontainerallows,cf.passingsectionof6.8.1.5).anotherThissegmentsegment(whichisisspecifiedusuallybytheheldinsegmentthe
registernumberintheadditionalobjref_segregoperand.
requiredTherulethatfortheparametersegmentssegmentsspecifiedisbyrelaxedobjref_segregfortheandlibrary_callparam_segreg.Itisonlyare
anheldinoperandtheforsamethecontainer.inter_module_callAdditionallythereturninstruction,valuewhichsegmentisalso(asusedtospecifiedreturnas
fromlibrarycalls)mustbestoredinthesamecontainer.
intlibrary_callint(ref_ttarget_mc,objref_segreg,intinttarget_ep,param_segreg)
Theinstructionfollowingthatimplicitlystack_sm_callusestheSegmentinstructionisManageravariantmoduleofthecapabilitylibrary_calldeposited
inhavesthethreadcompletelytableofidenticalatoprocess,theasdescribedlibrary_callinsectioninstruction.6.8.1.5.Otherwiseitbe-
intstack_sm_call(intsa_ep,intobjref_segreg,intparam_segreg)
ecutingAllthread.instructionsMethoddescribedininvocationthisandsectionreturnmodifyarethesynchronousstateoftheoperations.currentlyItex-is
possibletoimplementasynchronousmethodinvocationsindirectlybyexplicitlyas-
nextsociatingsectionthreadseitherwithdirectlymodules,orindirectlyusing.theinstructionswhicharedescribedinthe

ManagementThread.6ATheecutingprotectedthreadonthethread_switchcurrentCPUandinstructionloadsthesavesstatetheofstatetheofthreadthecurrentlyidentifiedex-by

240

AppendixAKernelInstructionReference

keepnew_threadtrackof.Thepreviousnewthreads.threadGenerallyimmediatelythestartsThreadexecution.SchedulerThemodulekernelisdoesrespons-not
iblethroughfortheselectingmemoryanewoperandthreadforakernel_capparticularisCPU.usedThetokernelcheckwhethercapabilitythisaccessiblekernel
instructionmaybeusedatall.
kernel_cap)ref_tnew_thread,(unique_idthread_switchoftheThefollowinginter_module_returnprotectedinstructionreturn_thread_switchandtheinstructionthread_switchisacombinationinstruction.
Itisexecutedindivisibly.Itspurposeistoavoidblockingthreadsinthecon-
textoftheThreadScheduler.SinceeachnodehasadifferentThreadScheduler
uleranditonisanodegenerallyothernotthanpossiblefortowhichinvokeitismethodsresponsible,ofathisparticularwouldThreadpreventSched-the
structionstraightforwardareamigrationcombinationofofthethreadstooperandsanotherofthenode.Theinter_module_returnoperandsofthisandin-
instructions.thethread_switchreturn_thread_switchref_t(unique_idkernel_cap)new_thread,intreturn_segreg,
Theprotectedinstructionshutdownimmediatelyterminatesthekernel.The
structionpersistentisvirtualused.Thememorycurrentmustbecontentofwrittenthetomainapersistentmemorywillmediumbelost.beforeThethiskernelin-
whethercapabilitythisaccessiblekernelthroughinstructionthemaybememoryusedatoperandall.kernel_capisusedtocheck
kernel_cap)(ref_tshutdownControloverthethreadexecutionontheprocessorsofanodeisprotectedby
ofkernelthesystem.capabilities.ItisnotThepossibleprotectiontoisgiveaallnecessarymodulesprerequisiteunrestrictedfortheaccesstoavailabilitythese
instructions(incontrasttotheinstructionsformoduleinvocation).

Synchronisation.7AThekernelimplementsreader/writersynchronisation[135]aspartoftheconsist-
encyprotocolfortheaccessestotheCo-moduleTable,CodeTableandThread
Tableandprovidesasetofsemaphoreinstructionsavailabletoanymodule.The
semanticsoftheseinstructionsandthecooperationwiththeThreadSchedulerare
6.6.7.sectionindescribedsemaphore)(ref_tsem_read_psem_read_vsem_write_p(ref_t(ref_tsemaphore)semaphore)
semaphore)(ref_tsem_write_v

.8AManagementMemoryVirtual

241

IfThesenecessarytheinstructionscurrentarealsothreadisexecutedblockedindivisiblylogically,likebeforeallothetherkernelinstruction.instructions.

ManagementMemoryVirtual.8APageframescanbeenteredintheMainMemoryPagetable(cf.section6.4.2)via
thethevirtualprotectedmemoryinstructionaddressmap_pagespecified.byThepagecontainerframeandpagepage_frame.Theisaccessmappedrightsat
ofthepagesaresetaccordingtothebasicaccessrightsinaccess_rights,which
kernelpotentiallycapabilitysupportsanaccessibleorthogonalthroughsettheofreadmemory,writeoperandandexecutekernel_capaccessisrights.usedTheto
checkwhetherthiskernelinstructionmaybeusedatall.
map_page(intpage_frame,container_idcontainer,intpage,
access_rights,intkernel_cap)ref_tbeLikewiseremovedpagesfromofthetheMainvirtualMemorymemoryPageT(specifiedablewithbythecontainerprotectedandpageunmap_page)can
inorderinstruction.toItavoidreturnsinformationthepageduplicationframeinwhichthewasMainassociatedMemoryPwithageTtheablegiven(MMPT)page
theandthememoryMainoperandMemoryDirectorykernel_capismodule.usedThetocheckkernelwhethercapabilitythiskernelaccessibleinstruthroughction
all.atusedbemayintunmap_page(container_idcontainer,intpage,
kernel_cap)ref_tbeUpdatesupdatedtobyatheMMPTmaliciousaremodulerestrictedthistowouldtrustworthcompromiseymodules,thebecauseprotectionifitmechan-could
isms.ThemodulewhichcanupdatetheMMPTcouldconstructarbitraryvirtual
memorycontentsandthusmanufacturemodulecapabilities.

SupportDriverDevice.9AThelastinstructiondescribedinthiskernelinstructionreferenceistheprotected
instructionwait_interrupt.Theoperandsourcespecifiesinwhichlistof
interrupthandlingthreadsthecurrentthreadshouldbeinserted(cf.section6.6.6.
toThecheckkernelwhethercapabilitythiskernelaccessibleinstructionthroughthemaybememoryusedatoperandall.kernel_capisused
kernel_cap)ref_tsource,(intwait_interruptGenerallyonlyhardwaredevicedriversandtheContainerDirectoryregistersuch
threads.Anormalmodulewillneverusethisinstruction.

242

Appendix

A

ernelK

Instruction

Reference

Zusammenfassung

243

denDerEntwurfStrukturierungsansatzaktuellerundBetriebssystemedieFlexibilitätundihrerihrerKernezeigtSchutzsysteme.MängelinDieBezugBetriebs-auf
systemeundAnwendungenleidenunterderfehlendenErweiterbarkeitundFlexi-
bilität.DasinvielenBetriebssystemenimplementierteSchutzmodellistnichtmäch-
tigdrückengenug,alsumdieVbeliebigeergabevonLese-Schutzbedingungenund/odermiteinerSchreibrechtenfeinerenaufGranularitätganzeObjekte.auszu-
tenAktuellenichtwirksamBetriebssystemekontrollieren.könnendenEinschränkungenInformationsflußkönnenzwischennichtdirektSoftwareeinhei-formuliert
werdenunddaherkönnenEinschränkungsproblemenurindirektgelöstwerden.
WeitereErschwernissemitdemSchutzsystemundbesondersderSoftwarestruk-
derturwerdenEinsatzdervomProzeßmodellMikrokern-Strukturin.EsmodernenistaußerordentlichBetriebssystemenschwierig,verursacht,diewieZugriffs-z.B.
hungrechtezwischenpassendderzuRolleformulieren,desKlientendaderunddenKlient/Server-AnsatzZugriffsrechtendeskeineServersdirektefestlegt.Bezie-
DieBeschränkungaufKlient/Server-StrukturenbevorzugteinezentraleServer-
modellsImplementierung.fürAnwendungenDieSpezifikationdurchdaseinesBetriebssystemSoftwareentwurfsverschlechtertundKihreommunikations-Struktur.
seAlssindFdieolgedieserAbstraktionvonBeobachtungAktivitätbenutztundsindSPEEDOSorthogonaldaszuAlternativmodell.ObjektennachProzes-dem
Geheimnisprinzip.DiesesModellwirdinvielenobjektorientiertenProgrammier-
sprachenundeinigenBetriebssystemeneingesetzt.DerMethodenaufrufwechselt
nichtzueinemanderenProzeß,sonderngibtdieAusführunganeinanderesObjekt
bietetkontrolliertjedochVweiterorteile,.DiesesweilderModellistProzeßbezeichbeinaheneräquivalentmiteinemzumSubjektKlient/Server-Ansatz,korreliert.Das
DievereinfachtzweidenwichtigstenSchutz,Mängel,verbessertdieabervonnichtdieserautomatischArbeitdasidentifiziertSchutzsystem.undangegan-
desgenwerden,BetriebssystemssinddieunddenAnpaßbarkeitAnwendungen.derDerZugriffsrechtsspezifikationEntwurfvonSPEEDOSunddiebetontStrukturdas
dungen,GleichgewichtumeinzwischenflexiblesdenundAufgabenerweiterbaresunddemGesamtsystemEinflußdeszuKernserhalten.undderAnwen-
denaufrufe.SPEEDOSDieseunterstütztAbfragenfreiwerdenprogrammierbaremitBracket-MethodenSchutzabfragenfürimplementiert,einzelnedieMetho-an-
derenentenorientiertenMethodenaufrufeabfangen.Programmiersprachen,DasKonzeptdiedasstammtZielaushaben,demdieKontextderSoftwarestrukturkompo-
überdenStandvonobjektorientiertenProgrammiersprachenhinauszuverbessern.

244

Zusammenfassung

ImBetriebssystemumfeldistderEinsatzdiesesKonzeptsneuunderlaubtdieIm-
plementierungvonSchutzabfragenundähnlichemaußerhalbdesKerns.Bracket-
Methodenkönnenz.B.denZugangzurZielmethodebasierendaufbeliebigenRe-
gelnverwehrenoderZugriffeprotokollieren.InanderenBetriebssystemenkannso
etwasnichtkomplettmitunprivilegiertenProgrammenimplementiertwerden.
BracketskönnenauchderKontrolledesInformationsflussesdienen,indemdie
IdentitätdesKlient-undZielmodulsunddieweitergegebeneInformationüberprüft
werden.InSPEEDOSgibteseinenweiterenMechanismus,dereserlaubtEinschrän-
kungsbedingungendurchzusetzen.DieserzusätzlicheMechanismus,derüberBits
inderbeimAufrufangegebenenCapabilitydesZielmodulsgesteuertwird,ergänzt
Bracket-basierteEinschränkungen,dieandereStärkenundSchwächenhaben.
EinweitererwichtigerGesichtspunktdesEntwurfsvonSPEEDOSistdieÜber-
tragungvielerPflichtendesBetriebssystemsaufdieeinzelnenAnwendungen.Der
EntwurfdesKernsbeschränktdieAufgabendesKernsausdrücklichaufgrundle-
gendeSicherheitsmechanismen.AlleStrategieentscheidungenwerdeninModulen
außerhalbdesKernsgetroffen.DieÜbertragungderAufgabendesBetriebssystems
andieeinzelnenAnwendungenistsinnvoll,wennlokaleslokalesAnwendungswis-
sengenutztwerdenkann.BestimmteBetriebsmittelverwaltungsaufgabenmüssen
inzentralenModulenimplementiertwerden,sonstwürdedieZuteilungseffizienz
leiden.VielestrukturelleProblemevonMikrokernenwerdenvermieden,wennEnt-
scheidungensodezentralalsmöglichgetroffenwerden.Mikrokernesindebenfalls
einVersuch,denKernzuverkleinern,erreichenabereinevölligandereundweni-
gerflexibleunderweiterbareStrukturdesBetriebssystemsundderAnwendungen.
DerKernimplementiertnurstrategie-neutraleMechanismenunddelegiertdie
StrategieandieBenutzermodule,umdieKerngrößezuminimieren.Dasmaximiert
alsbeabsichtigterSeiteneffektdieFlexibilitätundErweiterbarkeitdesBetriebssy-
stemsundderAnwendungen.DiesergibteinBetriebssystem,dessenEigenschaften
vollständigaußerhalbdesKernsbestimmtsind.DerBetriebssystemkernimplemen-
tiertnurwenigeMechanismen,welchediezugrundeliegendeProzessorarchitektur
imSinnezusätzlicherBefehleerweitern.DerGroßteildieserErweiterungenbe-
handeltsicherheitskritischeAspekte.InSPEEDOSrepräsentierenProzesseBenutzer
undnichtDienste,wasvieleSchutzproblemevermeidet.DieorthogonaleStruktur
basierendaufProzessenundModulensindderSchlüsselzueinemfreiprogram-
mierbarenSchutzsystem,basierendaufCapabilitiesundBracket-Methoden.
DerPrototypzeigt,daßdasinderBeschreibungderModulstrukturbenutzte
ModelldesvirtuellenSpeicherseffizientaufdiederzeitigenseitenbasiertenArchi-
tekturenabgebildetwerdenkann.EswirdkeinespezielleProzessorarchitekturbe-
nötigt,jedochwärenkleineErweiterungenanderHardware-Implementierungdes
virtuellenSpeicherswünschenswert.DiesdecktsichmitdenBeobachtungender
EntwicklerandererBetriebssystememitähnlichenAnforderungen.
DieEntwurfsbeschreibungindieserArbeitspiegeltdieErfahrungenbeiderIm-
plementierungdesPrototypswider.DerPrototyphalf,denEntwurfvonkleinen
FehlernundWidersprüchenzubefreien,jedochkonntendieÄnderungenausZeit-
gründenmeistnichtindenPrototypeingearbeitetwerden.

Bibliography

245

[1]InDavidA.ProceedingsAbramson.oftheFourthHardwareAustralianManagementComputerofaScienceLargeVirtualConference,Memorypages.
1981.Australia,QLD,Brisbane,1–13,[2]DavidAddressingAndrewinaLargeAbramson.VirtualComputerMemory.HardwarePhDtothesis,SupportMonashCapabilityUniversityBased,
1982.Australia,VIC,Clayton,[3]DavidA.Abramson.MONADS-PCMicroArchitectureManual.MONADS-PC
TClayton,echnicalRVIC,eport2,Australia,DepartmentOctoberof1985.ComputerScience,MonashUniversity,
[4]DavidA.AbramsonandJohnRosenberg.TheMicro-Architectureofa
WorkshopCapability-BasedonComputerMicroprogramming.In,pagesProceedings138–145,oftheNew19thYork,AnnualNY,USA,ACM/IEEEOcto-
1986.ber[5]MikeRashid,AAccetta,vadisRTobertevanian,V.JrBaron,.,andWilliamMichaelWBolosky.Y,oung.DavidB.Mach:Golub,ANewRichardKernelF.
FoundationforUNIXDevelopment.InProceedingsofSummerUsenix,pages
93–112,Atlanta,GA,USA,July1986.
[6]umeAdvanced1:ApplicationMicroDevices.ProgrammingAMD64.AdvancedArchitectureMicroDevices,Programmer’sInc.,ManualSunnyvale,Vol-
CA,USA,September2003.DocumentNumber24592.
[7]umeAdvanced2:SystemMicroProgrammingDevices..AMD64AdvancedArchitectureMicroDevices,Programmer’sInc.,Sunnyvale,ManualVCol-A,
USA,September2003.DocumentNumber24593.
[8]AdvancedMicroDevices.AMD64ArchitectureProgrammer’sManualVol-
umeInc.,3:Sunnyvale,General-PurposeCA,USA,andSeptemberSystem2003.Instructions.DocumentAdvancedNumberMicro24594.Devices,
[9]AdvancedMicroDevices.AMD64ArchitectureProgrammer’sManualVol-
CumeA,4:USA,128-BitSeptemberMedia2003.InstructionsDocument.AdvancedNumberMicro26568.Devices,Inc.,Sunnyvale,

246

Bibliography

[10]AdvancedMicroDevices.AMD64ArchitectureProgrammer’sManualVol-
ume5:64-BitMediaandx87Floating-PointInstructions.AdvancedMicro
Devices,Inc.,Sunnyvale,CA,USA,September2003.DocumentNumber
26569.[11]StanleyR.Ames,MorrieGasser,andRogerR.Schell.SecurityKernelDesign
andImplementation:AnIntroduction.IEEEComputer,16(7):14–22,July
1983.[12]MarkS.Anderson,RonaldD.Pose,andChrisS.Wallace.APassword-
CapabilitySystem.TechnicalReport52,MonashUniversity,Clayton,VIC,
Australia,March1985.Reprintedas[14].
[13]MarkS.AndersonandChrisS.Wallace.SecurityManagementina
Password-CapabilitySystem.TechnicalReport56,MonashUniversity,
1985.AugustAustralia,VIC,Clayton,[14]MarkS.Anderson,RonaldD.Pose,andChrisS.Wallace.APassword-
CapabilitySystem.TheComputerJournal,29(1):1–8,January1986.Re-
[12].fromprinted[15]DavidBarstow,editor.TheProgrammingLanguageADA:ReferenceManual,
volume155ofLectureNotesinComputerScience.Springer-Verlag,Heidel-
berg,Germany,1983.AmericanNationalStandardsInstituteANSI/MIL-
-1815A-1983.STD[16]MauriceGeorgeAshton.ManagementofData,Access,andConcurrencyin
PersistentSystems.PhDthesis,UniversityofNewcastle,Newcastle,NSW,
2004.MarchAustralia,[17]MalcolmP.Atkinson,PeterJ.Bailey,KennethChisholm,W.PaulCockshott,
andRonaldMorrison.AnApproachtoPersistentProgramming.TheCom-
puterJournal,26(4):360–365,November1983.
[18]MauriceJ.Bach.DesignoftheUNIXOperatingSystem.Prentice-Hall,Engle-
1986.USA,NJ,Cliffs,wood[19]GodmarBack,PatrickA.Tullmann,LeighStoller,WilsonC.Hsieh,andJay
Lepreau.JavaOperatingSystems:DesignandImplementation.Technical
ReportUUCS-98-015,DepartmentofComputerScience,UniversityofUtah,
SaltLakeCity,UT,USA,August1998.
[20]GodmarBack,WilsonC.Hsieh,andJayLepreau.ProcessesinKaffeOS:
Isolation,ResourceManagement,andSharinginJava.InProceedingsof
theFourthSymposiumonOperatingSystemsDesign&Implementation,pages
333–346,SanDiego,CA,USA,October2000.

Bibliography

247

[21]RobertV.Baron,RichardF.Rashid,EllenSiegel,AvadisTevanian,Jr.,and
MichaelW.Young.Mach-1:AnOperatingSystemEnvironmentforLarge-
ScaleMultiprocessorApplications.IEEESoftware,2(4):65–67,July1985.
[22]RobertV.Baron,DavidBlack,WilliamBolosky,JonathanChew,RichardP.
Draves,DavidB.Golub,RichardF.Rashid,AvadisTevanian,Jr.,andMi-
chaelW.Young.MACHKernelInterfaceManual.DepartmentofComputer
Science,Carnegie-MellonUniversity,Pittsburgh,PA,USA,1990.
[23]AlanP.BatsonandRobertE.Brundage.SegmentSizesandLifetimesinAlgol
60Programs.CommunicationsoftheACM,13(3):36–44,1977.
[24]LaszloA.Belady.AStudyofReplacementAlgorithmsforaVirtualStorage
Computer.IBMSystemsJournal,5(2):88–101,1966.
[25]DavidE.BellandLeonardJ.LaPadula.SecureComputerSystem:Math-
ematicalFoundations.TechnicalReportESD-TR-73-278,MitreCorporation,
1973.USA,MA,Bedford,[26]AndréBensoussan,CharlesT.Clingen,andRobertC.Daley.TheMUL-
TICSVirtualMemory:ConceptsandDesign.CommunicationsoftheACM,
1972.May15(5):308–318,[27]BrianN.Bershad,StefanSavage,PrzemyslawPardyak,EminGünSirer,
MarcE.Fiuczynski,DavidBecker,CraigChambers,andSusanJ.Eggers.
Extensibility,SafetyandPerformanceintheSPINOperatingSystem.InPro-
ceedingsofthe15thACMSymposiumonOperatingSystemPrinciples,pages
267–284,CopperMountainResort,CO,USA,December1995.ACMPress,
NewYork,NY,USA.
[28]ViktorsBerstis.SecurityandProtectionintheIBMSystem/38.InProceed-
ingsoftheSeventhSymposiumonComputerArchitecture,pages245–252,La
1980.MayFrance,Baule,[29]RalfBeschorner,KaiFuhrmeister,HeikoGolbs,RalfKujas,DirkLehmann,
ThomasMeyer,YorkWerres,andStephanWurst.Projektabschlußbericht
MonaLisa.Four-semesterstudentprojectattheUniversityofBremen,Ger-
1993.August,many[30]AllenC.Bomberger,WilliamS.Frantz,AnnC.Hardy,NormanHardy,
CharlesR.Landau,andJonathanS.Shapiro.TheKeyKOSNanokernel
Architecture.InProceedingsoftheUSENIXWorkshoponMicrokernelsand
OtherKernelArchitectures,Seattle,WA,USA,April1992.USENIXAssoci-
ation,Berkeley,CA,USA.
[31]MarthaBranstad,HomayoonTajalli,FrankMayer,andDavidDalva.Access
MediationinaMessagePassingKernel.InProceedingsofthe1989IEEE

248

Bibliography

SymposiumonSecurityandPrivacy,pages66–72,Oakland,CA,USA,May
1989.IEEEComputerSocietyPress,LosAlamitos,CA,USA.
[32]DavidF.C.BrewerandMichaelJ.Nash.TheChineseWallSecurityPolicy.
InProceedingsofthe1989IEEESymposiumonSecurityandPrivacy,pages
206–214,Oakland,CA,USA,May1989.IEEEComputerSocietyPress,Los
USA.A,CAlamitos,[33]PerBrinchHansen.TheNucleusofaMultiprogrammingSystem.Commu-
nicationsoftheACM,13(4):238–241,April1970.
[34]PerBrinchHansen.TheSoloOperatingSystem.Software–Practice&Exper-
1976.6(2):141–205,,ience[35]FrederickP.Brooks,Jr.NoSilverBullet—EssenceandAccidentinSoft-
wareEngineering.InHans-JürgenKugler,editor,ProceedingsoftheIFIP
10thWorldComputerCongress,InformationProcessing86,pages1069–1076,
Dublin,Ireland,September1986.North-Holland,Amsterdam,Netherlands.
[36].aseprintedR[36]FrederickP.Brooks,Jr.NoSilverBullet—EssenceandAccidentinSoftware
Engineering.IEEEComputer,20(4):10–19,April1987.Reprintedfrom[35].
[37]JohnL.Bruno,EranGabber,BanuÖzden,andAbrahamSilberschatz.The
EclipseOperatingSystem:ProvidingQualityofServiceviaReservationDo-
mains.InProceedingsoftheUSENIX1998AnnualTechnicalConference,pages
235–246,NewOrleans,LA,USA,June1998.USENIXAssociation,Berkeley,
USA.A,C[38]JohnL.Bruno,JoséC.Brustoloni,EranGabber,AbrahamSilberschatz,and
ChristopherSmall.Pebble:AComponent-BasedOperatingSystemforEm-
beddedApplications.InProceedingsofthe1999USENIXWorkshoponEm-
beddedSystems,pages55–66,Cambridge,MA,USA,March1999.USENIX
Association,Berkeley,CA,USA.
[39]Thomas‘Michael’Bushnell.TowardsaNewStrategyofOSDesign.GNU’s
1994.January1(16),,Bulletin[40]MauriceDavidCastro.TheWalnutKernel:APassword-CapabilityBasedOp-
eratingSystem.PhDthesis,MonashUniversity,Melbourne,VIC,Australia,
1996.January[41]VintonG.CerfandRobertE.Kahn.AProtocolforPacketNetworkInter-
communication.IEEETransactionsonCommunications,22(5):637–648,May
1984.[42]JeffreyS.Chase.AnOperatingSystemStructureforWide-AddressArchitec-
tures.PhDthesis,UniversityofWashington,Seattle,WA,USA,1995.

Bibliography

249

[43]J.BradleyChenandBrianN.Bershad.TheImpactofOperatingSystem
StructureonMemorySystemPerformance.InProceedingsofthe14thACM
SymposiumonOperatingSystemPrinciples,pages120–133,Asheville,NC,
USA,December1993.ACMPress,NewYork,NY,USA.
[44]AjayaChitturi.ImplementingMandatoryNetworkSecurityinaPolicy-
FlexibleSystem.Master’sthesis,DepartmentofComputerScience,Uni-
versityofUtah,SaltLakeCity,UT,USA,June1998.
[45]LesinW.Comeau.AStudyoftheEffectofUserProgramOptimisationina
PagingEnvironment.InProceedingsoftheFirstACMSymposiumonOperat-
ingSystemPrinciples,pages4.1–4.7,Gaitlinburg,TN,USA,October1967.
ACMPress,NewYork,NY,USA.
[46]Pierre-JacquesCourtois,FransHeymans,andDavidL.Parnas.Concur-
rentControlwith“Readers”and“Writers”.CommunicationsoftheACM,
1971.October14(10):667–668,[47]RussCox,EricGrosse,RobPike,DavidL.Presotto,andSeanQuinlan.Secur-
ityinPlan9.InProceedingsofthe11thUSENIXSecuritySymposium,pages
3–16,SanFrancisco,CA,USA,August2002.USENIXAssociation,Berkeley,
USA.A,C[48]StephenCrocker.HostSoftware.NetworkWorkingGroupRequestsfor
CommentsRFC1,UniversityofCaliforniaatLosAngeles,LosAngeles,CA,
1969.AprilUSA,[49]Ole-JohanDahlandKristenNygaard.SIMULA—AnALGOL-BasedSimu-
lationLanguage.CommunicationsoftheACM,9(9):671–678,September
1966.[50]RobertC.DaleyandJackB.Dennis.VirtualMemory,Processes,andSharing
inMULTICS.CommunicationsoftheACM,11(5):306–312,March1968.
[51]AlanDearle,JohnRosenberg,FransA.Henskens,FrancisVaughan,and
KevinMaciunas.AnExaminationofOperatingSystemSupportforPersistent
ObjectSystems.InProceedingsofthe25thHawaiiInternationalConferenceon
SystemSciences,volume1,pages779–789,Kauai,HI,USA,January1992.
IEEEComputerSocietyPress,LosAlamitos,CA,USA.
[52]AlanDearle,RexdiBona,JamesMatthewFarrow,AndersLindström,John
Rosenberg,andFrancisVaughan.Grasshopper:AnOrthogonallyPersistent
OperatingSystem.ComputingSystems,7(3):289–312,1994.
[53]AlanDearle,RexdiBona,JamesMatthewFarrow,FransA.Henskens,David
Hulse,AndersLindström,StephenNorris,JohnRosenberg,andFrancis
Vaughan.ProtectioninGrasshopper:APersistentOperatingSystem.In

250

Bibliography

ProceedingsoftheSixthInternationalWorkshoponPersistentObjectSystems,
pages60–78,Tarascon,France,September1994.
[54]AlanDearleandDavidHulse.OnPage-BasedOptimisticProcessCheck-
pointing.InProceedingsoftheFourthInternationalWorkshoponObjectOri-
entationinOperatingSystems,pages24–32,Lund,Sweden,August1995.
[55]PeterJ.Denning.TheWorkingSetModelforProgramBehavior.Communic-
ationsoftheACM,11(5):323–333,March1968.
[56]PeterJ.Denning.VirtualMemory.ACMComputingSurveys,2(3):153–189,
1970.September[57]DorothyE.Denning.ALatticeModelofSecureInformationFlow.Commu-
nicationsoftheACM,19(5):236–243,1976.
[58]JackB.DennisandEarlC.vanHorn.ProgrammingSemanticsforMultipro-
grammedComputations.CommunicationsoftheACM,9(3):143–155,March
1966.[59]RexdiBona,AlanDearle,JamesMatthewFarrow,FransA.Henskens,An-
dersLindström,JohnRosenberg,andFrancisVaughan.GenericInterface
forConfigurableDiskI/OSystems.InProceedingsofthe17thAnnualCom-
puterScienceConference,pages355–362,Christchurch,NewZealand,Janu-
1994.ary[60]EdsgerW.Dijkstra.CooperatingSequentialProcesses.TechnicalReport
EWD-123,DepartmentofMathematics,TechnologicalUniversityofEind-
1965.Netherlands,Eindhoven,hoven,[61]EdsgerW.Dijkstra.TheStructureofthe“THE”MultiprogrammingSystem.
CommunicationsoftheACM,11(5):341–346,May1968.
[62]EdsgerW.Dijkstra.ComplexityControlledbyHierarchicalOrderingof
FunctionandVariability.InProceedingsoftheNATOConferenceonSoft-
wareEngineering,pages181–185,Garmisch,Germany,October1968.Pet-
rocelli/Charter,NewYork,NY,USA.
[63]EdsgerW.Dijkstra.HierarchicalOrderingofSequentialProcesses.Acta
1971.1:115–138,,Informatica[64]LeendertvanDoorn.TheDesignandApplicationofanExtensibleOperating
System.PhDthesis,VrijeUniversiteitAmsterdam,Amsterdam,Netherlands,
2001.[65]SeanDorward,RobPike,DavidL.Presotto,DennisRitchie,HowardTrickey,
andPhilWinterbottom.Inferno.InProceedingsofthe42ndIEEEInterna-
tionalComputerConferenceCOMPCON97,pages241–244,SanJose,CA,
USA,February1997.IEEEComputerSocietyPress,LosAlamitos,CA,USA.

Bibliography

251

[66]RichardP.Draves,BrianN.Bershad,RichardF.Rashid,andRandallW.Dean.
UsingContinuationstoImplementThreadManagementandCommunica-
tioninOperatingSystems.InProceedingsofthe13thACMSymposiumon
OperatingSystemPrinciples,pages122–136,PacificGrove,CA,USA,Octo-
1991.ber[67]AntonEliëns.PrinciplesofObject-OrientedSoftwareDevelopment.Addison-
Wesley,Reading,MA,USA,1995.
[68]CarlM.EllisonandBruceSchneier.TenRisksofPKI:WhatYou’renotBeing
ToldaboutPublicKeyInfrastructure.ComputerSecurityJournal,16(1):1–7,
2000.[69]CarlM.EllisonandBruceSchneier.RisksofPKI:ElectronicCommerce.
CommunicationsoftheACM,43(2):152,February2000.
[70]KevinJ.Elphinstone,StephenRussel,andGernotHeiser.IssuesinImple-
mentingVirtualMemory.TechnicalReportUNSW-TR-CSE-9411,Schoolof
ComputerScienceandEngineering,UniversityofNewSouthWales,Sydney,
1994.Australia,,NSW[71]KevinJ.Elphinstone,GernotHeiser,andJochenLiedtke.L4Refer-
enceManual:MIPSR4x00.TechnicalReportUNSW-CSE-TR9709,School
ofComputerScienceandEngineering,UniversityofNewSouthWales,
Sydney,NSW,Australia,December1997.LatestversionavailableatURL:
.disy/.esu.au/.cse.unswhttp://www[72]KevinJohnElphinstone.VirtualMemoryina64-bitMicrokernel.PhDthesis,
SchoolofComputerScienceandEngineering,UniversityofNewSouth
Wales,Sydney,NSW,Australia,1999.
[73]DawsonR.Engler.TheExokernelOperatingSystemArchitecture.PhDthesis,
MassachusettsInstituteofTechnology,Cambridge,MA,USA,October1998.
[74]EuropeanCommunityAdvisoryGroupSOG-IS.InformationTechnologySe-
curityEvaluationCriteria(ITSEC):HarmonisedCriteriaofFrance,Germany,
theNetherlands,andtheUnitedKingdom,Version1.2.DepartmentofTrade
andIndustry,London,UK,June1991.
[75]MarkEveredandJ.LeslieKeedy.AModelforProtectioninPersistentObject-
OrientedSystems.InProceedingsoftheInternationalWorkshoponComputer
ArchitecturetoSupportSecurityandPersistenceofInformation,Workshops
inComputing,pages67–82,Bremen,Germany,May1990.Springer-Verlag,
.GermanyHeidelberg,[76]MarkEvered,MichaelKölling,andAxelSchmolitzky.AFlexibleObjectIn-
vocationLanguagebasedonObject-OrientedLanguageDefinition.TheCom-
1995.38(3):181–191,,Journalputer

252

Bibliography

[77]tionMarkEveredComponents.andInGiselaProceedingsMenger.ofVerytheHighConferenceLevelonTProgrammingechnologywithofObject-Collec-
JuneOriented1999.IEEELanguagesandComputerSystems,SocietyTOOLSPress,29,LospagesAlamitos,361–370,CA,USA.Nancy,France,

[78]MarkEvered.TypeOperatorsforRole-BasedObjectSecurity(WiP).In
wareACM/IFIP2001),InternationalHeidelberg,ConferenceGermany,onNovemberDistributed2001.PSystemsaperPlatformsavailableat(Middle-URL:
..org/0107/features/eve0107.htmhttp://dsonline.computer

[79]MarkceedingsEvered.ofthe25thBracketAustralasianCapabilitiesforComputerDistributedScienceSystemsConference,Securitypages.In51–58,Pro-
Melbourne,Darlinghurst,VIC,NSW,Australia,Australia.January2002.AustralianComputerSocietyInc.,

[80]MarkEvered.Opsis:ADistributedObjectArchitectureBasedonBracket
logyofCapabilities.InObject-OrientedProceedingsLanguagesoftheand40thSystemsInternational(TOOLSPConferenceacific2002)on,Techno-pages
Inc.,63–70,SydneyDarlinghurst,,NSW,NSW,Australia,Australia.January2002.AustralianComputerSociety,

[81]DavidC.FeldmeierandPhilipR.Karn.UNIXPasswordSecurityTen
YearsLater.InProceedingsoftheNinthAnnualInternationalCrypto-
logyConference,Crypto’89,volume435ofLectureNotesinComputerSci-
ence,pages44–53,SantaBarbara,CA,USA,August1989.Springer-
Verlag,Heidelberg,Germany.FulltextofthepaperavailableatURL:
..metapress.com/link.asp?id=ljy0753m9gwwkd6dhttp://springer

[82]DomenicoCommunicationsFerrari.oftheACMImproving,Program17(11):614–620,LocalitybyNovemberCritical1974.WorkingSets.

[83]MarcFleuryandFranciscoReverbel.TheJBossExtensibleServer.InPro-
ceedingsoftheInternationalMiddlewareConference,volume2672ofLec-
tureNotesinComputerScience,pages344–373,RiodeJaneiro,Brazil,
June2003.Springer-Verlag,Heidelberg,Germany.PaperavailableatURL:
..metapress.com/link.asp?id=3pge61v0tfqne41khttp://springer

[84]sionFluxR0.97esearch(SnapShotGroup.The20020317)OSKit:.TheTheFluxFluxResearchOperatingGroup,SystemDepartmentToolkit,Verof-
ComputerScience,UniversityofUtah,SaltLakeCity,UT,USA,March2002.
..cs.utah.edu/flux/oskit/doc/oskit.ps.gzhttp://wwwURL:

[85]InBryanThirdFordIEEEandJayInternationalLepreau.WorkshopMicrokernelsonShouldObject-OrientationSupportinPassiveOperatingObjects.Sys-
temsSociety,pagesPress,Los226–229,Alamitos,Asheville,CA,NC,USA.USA,December1993.IEEEComputer

Bibliography

253

[86]BryanFordandSaiSusarla.CPUInheritanceScheduling.InProceedingsof
theSecondUSENIXSymposiumonOperatingSystemsDesignandImplement-
ation,pages91–105,Seattle,WA,USA,October1996.USENIXAssociation,
USA.A,C,Berkeley[87]BryanFord,MikeHibler,JayLepreau,PatrickA.Tullmann,GodmarBack,
andStephenClawson.MicrokernelsMeetRecursiveVirtualMachines.In
ProceedingsoftheSecondUSENIXSymposiumonOperatingSystemsDesign
andImplementation,pages137–151,Seattle,WA,USA,October1996.
USENIXAssociation,Berkeley,CA,USA.
[88]BryanFord,KevinT.VanMaren,JayLepreau,StephenClawson,BartRobin-
son,andJeffTurner.TheFluxOSToolkit:ReusableComponentsforOS
Implementation.InProceedingsoftheSixthWorkshoponHotTopicsinOper-
atingSystems,pages14–19,CapeCod,MA,USA,May1997.IEEEComputer
SocietyPress,LosAlamitos,CA,USA.
[89]BryanFord,GodmarBack,GregBenson,JayLepreau,AlbertLin,andOlin
Shivers.TheFluxOSKit:ASubstrateforKernelandLanguageResearch.
InProceedingsofthe16thACMSymposiumonOperatingSystemPrinciples,
pages38–51,SaintMalo,France,October1997.ACMPress,NewYork,NY,
USA.[90]BryanFord,MikeHibler,JayLepreau,RolandMcGrath,andPatrickA.Tull-
mann.InterfaceandExecutionModelsintheFlukeKernel.InProceedings
oftheThirdSymposiumonOperatingSystemsDesignandImplementation,
pages101–115,NewOrleans,LA,USA,February1999.USENIXAssociation,
USA.A,C,Berkeley[91]AlessandroForin,DavidB.Golub,andBrianN.Bershad.AnI/OSystemfor
Mach3.0.InProceedingsoftheSecondUSENIXMachSymposium,pages163–
176,Monterey,CA,USA,November1991.USENIXAssociation,Berkeley,
USA.A,C[92]RichardFornoandWilliamFeinbloom.PKI:AQuestionofTrustandValue.
CommunicationsoftheACM,44(6):120,June2001.
[93]WilliamS.Frantz,NormanHardy,JayJonekait,andCharlesR.Landau.
GNOSIS:APrototypeOperatingSystemforthe1990’s.InProceedingsof
SHARE52,pages3–17,SanFrancisco,CA,USA,March1979.ShareInc.,
USA.IL,Chicago,[94]BerndFreisleben,PeterKammerer,andJ.LeslieKeedy.Capabilitiesand
Encryption:TheUltimateDefenseAgainstSecurityAttacks?InProceedings
oftheInternationalWorkshoponComputerArchitecturetoSupportSecurity
andPersistenceofInformation,WorkshopsinComputing,pages106–119,
Bremen,Germany,May1990.Springer-Verlag,Heidelberg,Germany.

254

Bibliography

[95]EranrahamGabber,Silberschatz.ChristopherTheSmall,PebbleJohnL.Component-BasedBruno,JoséC.OperatingBrustoloni,System.andAb-In
MontereyProceedings,CofA,theUSA,1999JuneUSENIX1999.AnnualUSENIXTechnicalAssociation,ConferenceBerkeley,,pagesCA,USA.267–282,

[96]forArtemistheMONADSGeorgiades,OperatingIanG.System.Richards,InandJ.ProceedingsLeslieofKtheeedy.EighthAFileAustralianSystem
ComputerConference,volume2,pages547–558,Canberra,ACT,Australia,
1978.

[97]JamesSpecificationGosling,.BillAddison-JoyW,Guyesley,RSteele,eading,andMA,GiladUSA,Bracha.secondTheedition,Java2000.Language

[98]NormanHardy.TheKeyKOSArchitecture.OperatingSystemsReview,
1985.October19(4):8–25,

[99]signee:NormanKeyHardyLogic,.U.S.Inc.,PatentCupertino,4,584,639:CA,USA,AprilComputer1986.SecuritySystem.As-

[100]HermannHärtig,MichaelHohmuth,JochenLiedtke,SebastianSchönberg,
ingsandofJeantheW16tholter.ACMThePSymposiumerformanceonofµOperating-Kernel-BasedSystemSystems.Principles,InpagesProceed-66–
77,SaintMalo,France,October1997.ACMPress,NewYork,NY,USA.

[101]ceedingsHermannoftheHärtig,FifthMichaelAustralasianHohmuth,andConferenceJeanonWPolterarallel.TamingandReal-Linux.TimeInPro-Sys-
tems,Adelaide,SA,Australia,September1998.

[102]DonaldMemory.J.IBMHatfieldSystemsandJournalJeanette,10(3),Gerald.1971.ProgramRestructuringforVirtual

[103]GernotHeiser,JeroenD.Vochteloo,KevinJ.Elphinstone,andStephenRus-
sell.TheMungikernelAPI:Release1.0.TechnicalReportUNSW-CSE-
TR9701,SchoolofComputerScienceandEngineering,UniversityofNew
SouthWales,Sydney,NSW,Australia,March1997.Latestversionavailable
atURL:http://www.cse.unsw.esu.au/disy/.

[104]theGernotMungiHeiser,FondySingle-Address-SpaceLam,andStephenOperatingRussel.System.ResourceInProceedingsManagementofthein
21stAustralia,AustraFlasianebruary1998.ComputerSpringer-ScienceVerlag,Conference,Heidelberg,pages417–428,Germany.Perth,WA,

[105]GernotHeiser,KevinJ.Elphinstone,JeroenD.Vochteloo,StephenRussell,
andJochenLiedtke.TheMungiSingle-Address-SpaceOperatingSystem.
Software–Practice&Experience,28(9):901–928,July1998.

Bibliography

255

[106]FransA.Henskens,JohnRosenberg,andMichaelR.Hannaford.Stability
inaNetworkofMonads-PCComputers.InProceedingsoftheInternational
WorkshoponComputerArchitecturestoSupportSecurityandPersistenceof
Information,WorkshopsinComputing,pages246–256,Bremen,Germany,
May1990.Springer-Verlag,Heidelberg,Germany.

[107]FransMemoryA..PhDHenskens.thesis,ACapabilityUniversityof-BasedNewcastle,PersistentNewcastle,DistributedNSW,SharedAustralia,Virtual
1991.

[108]FransA.Henskens.Personalcommunication,March2002.

[109]MichaelHitchens.TheStructureofaCommandLanguageInterpreter.In
197–211,ProceedingsofNapatheVFalleyourth,CA,IFIPUSAW,orkingAugust1989.ConferenceonNorth-Holland,UserInterfaces,Amsterdam,pages
Netherlands.

[110]MichaelLanguageHitchens.Interpreter.ThePhDDesignthesis,andUniversityImplementationofNewcastle,ofaGenericNewcastle,CommandNSW,
1991.Australia,

[111]CharlesConcept.AntonyCommunicationsRichardHoare.oftheACMMonitors:,An17(10):549–557,OperatingSystemOctober1974.Structuring

[112]MerleSupportE.forHoudek,Capability-BasedFrankG.Soltis,Addressing.andRInoyL.ProceedingsHoffman.oftheIBMEighthSystem/38Sym-
posiumonComputerArchitecture,pages341–348,Minneapolis,MN,USA,
1981.May

[113]DavidJ.Howarth,R.B.Payne,andFrankH.Sumner.TheManchesterUni-
versityAtlasOperatingSystemPartII:Users’Description.TheComputer
1961.October4(3):226–229,,Journal

[114]aDavidCustomisableHulseandPAlanersistentDearle.Micro-Kernel.TrendsinTechnicalOperatingReportSystemPastelDesign:RTT1R4,owardsUni-
versityofStirling,Stirling,Scotland,UK,August1998.Paperavailableat
.http://os.dcs.st-and.ac.uk/Charm/papers/persmicrokernel.pdfURL:

[115]InstituteofElectricalandElectronicsEngineers.POSIX1003.1eStandard,
DraftControl17,PartInterfaces1,System(withdrawn)Application.InstituteProgramofElectricalInterface:andProtection,ElectronicsAuditEngin-and
eersInc.,NewYork,NY,USA,October1997.

[116]InstituteofElectricalandElectronicsEngineers.POSIX1003.2cStandard,
Draftdrawn).17,PartInstitute2,ofShellandElectricalUtilities:andElectronicsProtectionandEngineersControlInc.,NewInterfacesYork,(with-NY,
1997.OctoberUSA,

256

Bibliography

[117]IntelCorporation.IntelItaniumArchitectureSoftwareDeveloper’sManual,
Volume1:ApplicationArchitecture.IntelCorporation,Denver,CO,USA,
October2002.DocumentNumber245317,Fulltextofthemanualavailable
..intel.com/design/itanium/manuals/245317.pdfhttp://developerURL:at[118]IntelCorporation.IntelItaniumArchitectureSoftwareDeveloper’sManual,
Volume2:SystemArchitecture.IntelCorporation,Denver,CO,USA,October
2002.DocumentNumber245318,FulltextofthemanualavailableatURL:
..intel.com/design/itanium/manuals/245318.pdfhttp://developer[119]IntelCorporation.IntelItaniumArchitectureSoftwareDeveloper’sManual,
Volume3:InstructionSetReference.IntelCorporation,Denver,CO,USA,
October2002.DocumentNumber245319,Fulltextofthemanualavailable
..intel.com/design/itanium/manuals/245319.pdfhttp://developerURL:at[120]IntelCorporation.IA-32IntelArchitectureSoftwareDeveloper’sManual,
Volume1:BasicArchitecture.IntelCorporation,Denver,CO,USA,2004.
DocumentNumber253665,FulltextofthemanualavailableatURL:
.entium4/manuals/253665.pdf.intel.com/design/Phttp://developer[121]IntelCorporation.IA-32IntelArchitectureSoftwareDeveloper’sManual,Vol-
ume2A:InstructionSetReferenceA–M.IntelCorporation,Denver,CO,USA,
2004.DocumentNumber253666,FulltextofthemanualavailableatURL:
.entium4/manuals/253666.pdf.intel.com/design/Phttp://developer[122]IntelCorporation.IA-32IntelArchitectureSoftwareDeveloper’sManual,Vol-
ume2B:InstructionSetReferenceN–Z.IntelCorporation,Denver,CO,USA,
2004.DocumentNumber253667,FulltextofthemanualavailableatURL:
.entium4/manuals/253667.pdf.intel.com/design/Phttp://developer[123]IntelCorporation.IA-32IntelArchitectureSoftwareDeveloper’sManual,Vol-
ume3:SystemProgrammingGuide.IntelCorporation,Denver,CO,USA,
2004.DocumentNumber253668,FulltextofthemanualavailableatURL:
.entium4/manuals/253668.pdf.intel.com/design/Phttp://developer[124]InternationalOrganizationforStandardization.ISO/IEC7498-1:1994Open
SystemsInterconnection–BasicReferenceModel:TheBasicModel.Interna-
tionalOrganizationforStandardization,Geneva,Switzerland,1994.
[125]RasoolJalili.AFailure-TransparentDistributedPersistentStore.PhDthesis,
UniversityofSydney,Sydney,NSW,Australia,1995.
[126]AnitaK.Jones.CapabilityArchitectureRevisited.OperatingSystemsReview,
1980.July14(3):33–35,[127]RobertE.KahnandWilliamR.Crowther.AStudyoftheARPANetwork
DesignandPerformance.TechnicalReportBBN-2161,Bolt,Beranekand
Newman,Inc.,Cambridge,MA,USA,August1971.

Bibliography

257

[128]PaulAshleyKarger.ImprovingSecurityandPerformanceforCapabilitySys-
tems.PhDthesis,ComputerLaboratory,UniversityofCambidge,Cambridge,
1988.OctoberUK,[129]J.LeslieKeedy.OnStructuringOperatingSystemswithMonitors.TheAus-
tralianComputerJournal,10(1):23–27,February1978.Reprintedas[132].
[130]J.LeslieKeedy.TheInfluenceoftheInformation-HidingPrincipleonthe
MONADSOperatingSystem.InProceedingsoftheAustralianUniversities
ComputerScienceSeminar,pages1–7,Sydney,NSW,Australia,1978.
[131]J.LeslieKeedy.TheMONADSOperatingSystem.InProceedingsoftheEighth
AustralianComputerConference,volume2,pages903–910,Canberra,ACT,
1978.Australia,[132]J.LeslieKeedy.OnStructuringOperatingSystemswithMonitors.ACM
OperatingSystemsReview,13(1):5–13,January1979.
[133]J.LeslieKeedy,KotagiriRamamohanarao,andJohnRosenberg.OnImple-
mentingSemaphoreswithSets.TheComputerJournal,22(2):146–150,May
1979.[134]J.LeslieKeedy.PagingandSmallSegments:AMemoryManagementModel.
InProceedingsoftheIFIP-80,EighthWorldComputerCongress,pages337–
342,Melbourne,VIC,Australia,October1980.
[135]J.LeslieKeedy,JohnRosenberg,andKotagiriRamamohanarao.OnSyn-
chronizingReadersandWriterswithSemaphores.TheComputerJournal,
1982.ebruaryF25(1):121–125,[136]J.LeslieKeedy.AnImplementationofCapabilitieswithoutaCentralMap-
pingTable.InProceedingsofthe17thHawaiiInternationalConferenceon
SystemSciences,pages180–185,Honolulu,HI,USA,January1984.
[137]J.LeslieKeedyandDavidA.Abramson.ImplementingaLargeVirtual
MemoryinaDistributedComputingSystem.InProceedingsofthe18th
HawaiiInternationalConferenceonSystemSciences,pages515–522,Hon-
1985.JanuaryUSA,HI,olulu,[138]J.LeslieKeedyandBerndFreisleben.OntheEfficientUseofSemaphore
Primitives.InformationProcessingLetters,21(4):199–205,October1985.
[139]J.LeslieKeedy,PeterBrössler,FransA.Henskens,andJohnRosenberg.Ad-
dressingObjectsinaVeryLargeDistributedSystem.InProceedingsofthe
IFIPConferenceonDistributedSystems,pages105–116,Amsterdam,Nether-
1987.lands,

258

Bibliography

[140]J.LeslieKeedyandJohnRosenberg.SupportforObjectsintheMONADS
Architecture.InProceedingsoftheInternationalWorkshoponPersistentOb-
jectSystems,WorkshopsinComputing,pages202–213,Newcastle,NSW,
Australia,January1989.Springer-Verlag,Heidelberg,Germany.
[141]J.LeslieKeedyandKarinVosseberg.PersistentProtectedModulesandPer-
sistentProcessesastheBasisforaMoreSecureOperatingSystem.InPro-
ceedingsofthe25thHawaiiInternationalConferenceonSystemSciences,vol-
ume1,pages747–756,Kauai,HI,USA,1992.IEEEComputerSocietyPress,
USA.A,CAlamitos,Los[142]J.LeslieKeedy,MarkEvered,AxelSchmolitzky,andGiselaMenger.Attribute
TypesandBracketImplementations.InProceedingsoftheConferenceon
TechnologyofObject-OrientedLanguagesandSystems,TOOLS25,pages325–
337,Melbourne,VIC,Australia,November1997.IEEEComputerSociety
Press,LosAlamitos,CA,USA.
[143]J.LeslieKeedy,KlausEspenlaub,GiselaMenger,AxelSchmolitzky,andMark
Evered.SoftwareReuseinanObjectOrientedFramework:Distinguishing
TypesfromImplementationsandObjectsfromAttributes.InProceedingsof
theSixthInternationalConferenceonSoftwareReuse:AdvancesinReusab-
ility,volume1844ofLectureNotesinComputerScience,pages420–435,
Vienna,Austria,June2000.Springer-Verlag,Heidelberg,Germany.URL:
..metapress.com/link.asp?id=ql8kv4x1e27fdl7mhttp://springer[144]J.LeslieKeedy,KlausEspenlaub,RolandHellmann,andRonaldPose.
SPEEDOS:HowtoAchieveHighSecurityandUnderstandIt,September
2000.[145]J.LeslieKeedy,GiselaMenger,andChristianHeinlein.Inheritingfroma
CommonAbstractAncestorinTimor.JournalofObjectTechnology,1(1):81–
106,2002.URL:http://www.jot.fm/jot/issues/issue_2002_05/article2.
[146]J.LeslieKeedy,GiselaMenger,andChristianHeinlein.SupportforSub-
typingandCodeRe-useinTimor.InProceedingsofthe40thInternational
ConferenceonTechnologyofObject-OrientedLanguagesandSystems(TOOLS
Pacific2002),pages35–43,Sydney,NSW,Australia,February2002.Aus-
tralianComputerSocietyInc.,Darlinghurst,NSW,Australia.
[147]J.LeslieKeedy,GiselaMenger,ChristianHeinlein,andFransA.Henskens.
QualifyingTypesIllustratedbySynchronisationExamples.InProceedings
oftheInternationalConferenceNetObjectDays,NODe2002,pages334–348,
Erfurt,Germany,October2002.Springer-Verlag,Heidelberg,Germany.
[148]J.LeslieKeedy,GiselaMenger,ChristianHeinlein,andFransA.Henskens.
QualifyingTypesIllustratedbySynchronisationExamples.InProceedings

Bibliography

259

oftheInternationalConferenceNetObjectDays,NODe2002,RevisedPapers,
volume2591ofLectureNotesinComputerScience,pages330–344.Springer-
Verlag,Heidelberg,Germany,Erfurt,Germany,2003.Paperavailableat
..metapress.com/link.asp?id=q6ylnm4jhh5v8t3khttp://springerURL:[149]J.LeslieKeedy,KlausEspenlaub,GiselaMenger,andChristianHein-
lein.QualifyingTypeswithBracketMethodsinTimor.JournalofOb-
jectTechnology,3(1):101–121,2004.PaperavailableonlineatURL:
..jot.fm/issues/issue_2004_01/article1http://www[150]J.LeslieKeedy.StructuringComplexSystems,2004.LectureSlides.
[151]J.LeslieKeedy.SecureSystemArchitecture,2004.LectureSlides.
[152]J.LeslieKeedy,KlausEspenlaub,ChristianHeinlein,andGiselaMenger.
StaticallyQualifiedTypesinTimor.JournalofObjectTechnology,54(1),
publication.forAccepted2005.[153]J.LeslieKeedy,KlausEspenlaub,ChristianHeinlein,andGiselaMenger.
Call-OutBracketMethodsinTimor.JournalofObjectTechnology,5(1),2006.
publication.forAccepted[154]J.LeslieKeedy,KlausEspenlaub,ChristianHeinlein,GiselaMenger,FransA.
Henskens,andMichaelR.Hannaford.SupportforObjectOrientedTrans-
actionsinTimor.JournalofObjectTechnology,5(2),2006.Acceptedfor
publication.[155]RichardA.Kemmerer.APracticalApproachtoIdentifyingStorageandTim-
ingChannels.InProceedingsofthe1982IEEESymposiumonSecurityand
Privacy,pages66–73,Oakland,CA,USA,April1982.
[156]BrianW.KernighanandDennisM.Ritchie.TheCProgrammingLanguage.
Prentice-Hall,EnglewoodCliffs,NJ,USA,firstedition,1978.
[157]GregorKiczales,JohnLamping,AnuragMendhekar,ChrisMaeda,Cristina
Lopes,Jean-MarcLoingtier,andJohnIrwin.Aspect-OrientedProgramming.
In11thEuropeanConferenceonObject-OrientedProgramming,ECOOP’97,
volume1241ofLectureNotesinComputerScience,pages220–242,Jyväs-
kylä,Finland,June1997.Springer-Verlag,Heidelberg,Germany.Available
..metapress.com/link.asp?id=8tkwabbf6q7dbtb3http://springerURL:at[158]TomKilburn,DavidJ.Howarth,R.B.Payne,andFrankH.Sumner.The
ManchesterUniversityAtlasOperatingSystemPartI:InternalOrganisation.
TheComputerJournal,4(3):222–225,October1961.
[159]TomKilburn,DavidB.G.Edwards,M.J.Lanigan,andFrankH.Sumner.
OneLevelStorageSystem.IRETransactionsonElectronicComputers,EC-
1962.April11(2):223–235,

260

Bibliography

[160]DonaldE.Knuth.FundamentalAlgorithms,volume1ofTheArtofComputer
Programming.Addison-Wesley,Reading,MA,USA,thirdedition,1997.
[161]DonaldE.Knuth.SeminumericalAlgorithms,volume2ofTheArtofCom-
puterProgramming.Addison-Wesley,Reading,MA,USA,thirdedition,1997.
[162]DonaldE.Knuth.SortingandSearching,volume3ofTheArtofComputer
Programming.Addison-Wesley,Reading,MA,USA,secondedition,1998.
[163]DavidKotzandPrestonCrow.TheExpectedLifetimeof“Single-Address-
Space”OperatingSystems.TechnicalReportPCS-TR93-198,DartmouthCol-
lege,Hanover,NH,USA,March1996.Originalversionpublished1993.
[164]ButlerW.Lampson.OnReliableandExtendibleOperatingSystems.InPro-
ceedingsoftheSecondNATOConferenceonTechniquesinSoftwareEngineer-
ing,Rome,Italy,October1969.Petrocelli/Charter,NewYork,NY,USA.
[165]ButlerW.Lampson.Protection.InProceedingsoftheFifthPrincetonSym-
posiumonInformationSciencesandSystems,pages437–443,March1971.
[166].aseprintedR[166]ButlerW.Lampson.Protection.ACMOperatingSystemsReview,8(1):18–24,
January1974.Reprintedfrom[165].
[167]ButlerW.LampsonandHowardE.Sturgis.ReflectionsonanOperating
SystemDesign.CommunicationsoftheACM,19(5):251–265,May1976.
[168]ButlerW.LampsonandRobertF.Sproull.AnOpenOperatingSystemfora
Single-UserMachine.InProceedingsoftheSeventhSymposiumonOperating
SystemPrinciples,pages98–105,PacificGrove,CA,USA,December1979.
[169]HughC.LauerandRogerM.Needham.OntheDualityofOperatingSystem
Structures.ACMOperatingSystemsReview,13(2):3–19,April1979.
[170]GregLaw.ANewProtectionModelforComponent-BasedOperatingSystems.
PhDthesis,CityUniversity,London,UK,October2001.
[171]IanM.Leslie,DerekMcAuley,RichardBlack,TimothyRoscoe,PaulT.Bar-
ham,DavidEvers,RobinFairbairns,andEoinHyden.TheDesignandIm-
plementationofanOperatingSystemtoSupportDistributedMultimedia
Applications.IEEEJournalofSelectedAreasinCommunications,14(7):1280–
1996.September1297,[172]RoyLevin,EllisS.Cohen,WilliamM.Corwin,FredJ.Pollack,andWilliamA.
Wulf.Policy/MechanismSeparationinHYDRA.InProceedingsoftheFifth
SymposiumonOperatingSystemPrinciples,pages132–140,Austin,TX,USA,
November1975.ACMPress,NewYork,NY,USA.

Bibliography

261

[173]HenryM.Levy.Capability-BasedComputerSystems.DigitalPress,Bedford,
MA,USA,1984.Outofprint,fulltextofentirebookavailableatURL:
..cs.washington.edu/homes/levy/capabook/http://www[174]KaiLi.SharedVirtualMemoryonLooselyCoupledMultiprocessors.PhDthesis,
DepartmentofComputerScience,YaleUniversity,NewHaven,CT,USA,
1986.September[175]JochenLiedtke.Clans&Chiefs.InProceedingsofArchitekturvonRechensyste-
men,12.GI/ITG-Fachtagung,pages294–305,Kiel,Germany,March1992.
[176]JochenLiedtke.AHighResolutionMMUfortheRealizationofHugeFine-
grainedAddressSpacesandUserLevelMapping.TechnicalReportNo.791,
GMD—GermanNationalResearchCenterforInformationTechnology,Sankt
1993.October,GermanyAugustin,[177]JochenLiedtke.APersistentSysteminRealUse:ExperiencesoftheFirst
13Years.InProceedingsoftheThirdInternationalWorkshoponObject-
OrientationinOperatingSystems,pages2–11,Asheville,NC,USA,December
1993.[178]JochenLiedtkeandKevinJ.Elphinstone.GuardedPageTablesontheMIPS
R4600.TechnicalReportUNSW-TR-CSE-9503,SchoolofComputerScience
andEngineering,UniversityofNewSouthWales,Sydney,NSW,Australia,
1995.November[179]JochenLiedtke.ImprovedAddress-SpaceSwitchingonPentiumProcessors
byTransparentlyMultiplexingUserAddressSpaces.TechnicalReportNo.
933,GMD—GermanNationalResearchCentreforInformationTechnology,
SanktAugustin,Germany,November1995.
[180]JochenLiedtke.Onµ-KernelConstruction.InProceedingsofthe15thACM
SymposiumonOperatingSystemPrinciples,pages237–250,CopperMoun-
tainResort,CO,USA,December1995.ACMPress,NewYork,NY,USA.
[181]JochenLiedtke.µ-KernelsMustAndCanBeSmall.InProceedingsofthe
FifthIEEEInternationalWorkshoponObject-OrientationinOperatingSys-
tems,pages152–155,Seattle,WA,USA,October1996.
[182]JochenLiedtke,UweDannowski,KevinJ.Elphinstone,GerdLiefländer,Es-
penSkoglund,VolkmarUhlig,ChristianCeelen,AndreasHaeberlen,and
MarcusVölp.TheL4KaVision,April2001.WhitePaper.
[183]AndersLindstrom,AlanDearle,RexdiBona,JamesMatthewFarrow,
FransA.Henskens,JohnRosenberg,andFrancisVaughan.AModelfor
User-LevelMemoryManagementinaPersistentDistributedEnvironment.
InProceedingsofthe17thAnnualComputerScienceConference,pages343–
354,Christchurch,NewZealand,January1994.

262

Bibliography

[184]AndersLindström,JohnRosenberg,andAlanDearle.TheGrandUnified
TheoryofAddressSpaces.InProceedingsoftheFifthWorkshoponHotTopics
inOperatingSystems,pages66–71,OrcasIsland,WA,USA,May1995.
[185]AndersLindström.VersioningandLoggingintheGrasshopperPersistent
Store.InProceedingsoftheFourthInternationalWorkshoponObjectOrient-
ationinOperatingSystems,pages14–23,Lund,Sweden,August1995.
[186]AndersLindström,AlanDearle,RexdiBona,StephenNorris,JohnRosen-
berg,andFrancisVaughan.PersistenceintheGrasshopperKernel.InPro-
ceedingsofthe18thAustralianComputerScienceConference,pages329–338,
Glenelg,SA,Australia,February1995.
[187]BarbaraH.Liskov.TheDesignoftheVenusOperatingSystem.Communica-
tionsoftheACM,15(3):144–149,March1972.
[188]ThomasMarillandLawrenceG.Roberts.TowardaCooperativeNetwork
ofTime-SharedComputers.InProceedingsoftheFallJointComputerCon-
ference,volume29ofAFIPSConferenceProceedings,pages425–431,San
Francisco,CA,USA,November1966.AFIPSPress,Montvale,NJ,USA.
[189]DavidMazièresandM.FransKaashoek.SecureApplicationsNeedFlexible
OperatingSystems.InProceedingsoftheSixthWorkshoponHotTopicsin
OperatingSystems,pages56–61,CapeCod,MA,USA,May1997.IEEECom-
puterSocietyPress,LosAlamitos,CA,USA.
[190]JohnMcHugh.CovertChannelAnalysis.InNavyHandbookfortheCom-
puterSecurityCertificationofTrustedSystems,chapter8.TheNavalResearch
Laboratory,CenterforHighAssuranceComputingSystems,December1995.
[191]M.DouglasMcIlroy.MassProducedSoftwareComponents.InProceedings
oftheNATOConferenceonSoftwareEngineering,pages138–155,Garmisch,
Germany,October1968.Petrocelli/Charter,NewYork,NY,USA.
[192]GiselaMenger,J.LeslieKeedy,MarkEvered,andAxelSchmolitzky.Collec-
tionTypesandImplementationsinObject-OrientedSoftwareLibraries.In
ProceedingsoftheConferenceonTechnologyofObject-OrientedLanguagesand
Systems,TOOLS26,pages97–109,SantaBarbara,CA,USA,August1998.
IEEEComputerSocietyPress,LosAlamitos,CA,USA.
[193]SpencerE.Minear.ProvidingPolicyControlOverObjectOperationsina
MachBasedSystem.InProceedingsoftheFifthUSENIXUNIXSecuritySym-
posium,pages141–156,SaltLakeCity,UT,USA,June1995.USENIXAsso-
ciation,Berkeley,CA,USA.
[194]RobertMorrisandKenThompson.PasswordSecurity—ACaseHistory.Com-
municationsoftheACM,22(11):594–597,November1979.

Bibliography

263

[195]WUniversityilhelmofMüllerBremen,andPeterGermanyBrössler,1993..MONADSPS-Pascal.InternalReport,

[196]SapeJ.MullenderandAndrewS.Tanenbaum.TheDesignofaCapability-
BasedDistributedOperatingSystem.TheComputerJournal,29(4):289–299,
1986.August

[197]KevinMurray,TimWilkinson,PeterOsmon,AshleySaulsbury,TomStiemer-
ling,andPaulKelly.DesignandImplementationofanObject-Oriented64-
bitSingleAddressSpaceMicrokernel.InProceedingsoftheUSENIXMicroker-
nelsandOtherKernelArchitecturesSymposium,pages31–44,SanDiego,CA,
USA,September1993.USENIXAssociation,Berkeley,CA,USA.

[198]PeterNaurandBrianRandell,editors.SoftwareEngineering:Reportona
ConferencesponsoredbytheNATOScienceCommittee,Garmisch,Germany,
October1968.Petrocelli/Charter,NewYork,NY,USA.

[199]RogerM.Needham.ProtectionSystemsandProtectionImplementations.
InConferenceProceedingsofProceedingstheF,allpagesJoint571–578,ComputerAnaheim,ConferenceCA,,USA,volumeDecember41of1972.AFIPS
USA.NJ,Montvale,Press,AFIPS

[200]RitsogerM.ProtectionNeedhamSystem.andACMR.D.H.OperatingWalker.TheSystemsRCambridgeeview,CAP11(5):1–10,ComputerNovem-and
ber1977.ProceedingsoftheSixthACMSymposiumonOperatingSystem
Principles.

[201]RogerM.NeedhamandAndrewD.Birrell.TheCAPFilingSystem.ACM
OperatingSystemsReview,11(5):11–16,November1977.Proceedingsof
theSixthACMSymposiumonOperatingSystemPrinciples.

[202]RogerM.Needham.TheCAPProject–anInterimEvaluation.ACMOperat-
ingSystemsReview,11(5):17–22,November1977.ProceedingsoftheSixth
ACMSymposiumonOperatingSystemPrinciples.

[203]RogernationalM.WorkshopNeedham.onComputerCapabilitiesandArchitecturesSecurityto.InSupportProceedingsSecurityofandthePInterersist--
Mayenceof1990.InformationSpringer-,WVerlag,orkshopsinHeidelberg,Computing,Germanypages.3–8,Bremen,Germany,

[204]PeterLawrenceG.RNeumann,obinson.RAobertS.ProvablyBoyer,SecureRichardJ.OperatingFeiertag,System:KarlN.TheLevitt,System,and
itsLaboratoryApplications,,SRIandInternational,Proofs.TMenloechnicalPark,RCeportA,CUSA,SL-116,May1980.ComputerScience

264

Bibliography

[205]PeterG.NeumannandRichardJ.Feiertag.PSOSRevisited.InProceedings
ofthe19thAnnualComputerSecurityApplicationsConference,pages208–
216,LasVegas,NV,USA,December2003.IEEEComputerSocietyPress,Los
USA.A,CAlamitos,[206]AdrianNye.VolumeOne:XlibProgrammingManual.TheDefinitiveGuides
totheXWindowSystem.O’Reilly&Associates,Sebastopol,CA,USA,third
1992.edition,[207]AdrianNye,editor.VolumeTwo:XlibReferenceManual.TheDefinitive
GuidestotheXWindowSystem.O’Reilly&Associates,Sebastopol,CA,USA,
1992.edition,third[208]AdrianNye.Volume0:XProtocolReferenceManual.TheDefinitiveGuides
totheXWindowSystem.O’Reilly&Associates,Sebastopol,CA,USA,fourth
1995.edition,[209]ObjectManagementGroup.CommonObjectRequestBrokerArchitecture:
CoreSpecification.ObjectManagementGroup,Inc.,Needham,MA,USA,
2002.December[210]DuaneE.Olawsky,ToddFine,EdwardSchneider,andRaySpencer.Devel-
opingandUsinga“PolicyNeutral”AccessControlPolicy.InProceedingsof
theNewSecurityParadigmsWorkshop,pages60–67,LakeArrowhead,CA,
USA,June1996.ACMPress,NewYork,NY,USA.
[211]TheOpenGroup.DCE1.2.2F201:IntroductiontoOSFDCE,November
1997.[212]ElliotI.Organick.TheMULTICSSystem:AnExaminationofitsStructure.The
MITPress,Cambridge,MA,USA,1972.
[213]ElliotI.Organick.AProgrammer’sViewoftheIntel432System.McGraw-Hill,
NewYork,NY,USA,1983.
[214]RichardJ.Pankhurst.OperatingSystems:ProgramOverlayTechniques.
CommunicationsoftheACM,11(2):119–125,February1968.
[215]DavidL.Parnas.InformationDistributionAspectsofDesignMethodology.In
ProceedingsoftheIFIPCongress1971,volume1,pages339–344,Ljubljana,
Yugoslavia,August1971.North-Holland,Amsterdam,Netherlands.
[216]DavidL.Parnas.ATechniqueforSoftwareModuleSpecificationwithEx-
amples.CommunicationsoftheACM,15(5):330–336,May1972.
[217]DavidL.Parnas.OntheCriteriatobeUsedinDecomposingSystemsinto
Modules.CommunicationsoftheACM,15(12):1053–1058,December1972.

Bibliography

265

[218]ofDavidtheL.IFIPP-74,arnas.SixthOnWaorld“Buzzword”:ComputerCongressHierarchical,pagesStructure.336–339,InProceedingsStockholm,
1974.AugustSweden,

[219]RobHowardPike,TrickeyDavid,L.andPhilPresotto,WSeaninterbottom.Dorward,PlanBob9fromFlandrena,BellKLabs.enThompson,Computing
1995.8(3):221–254,,Systems

[220]USA,DavidS.thirdPlatt.edition,IntroducingMay2003.Microsoft.NET.MicrosoftPress,Redmond,WA,

[221]Rthesis,onaldD.MonashPose.AUniversity,CapabilityClayton,-BasedVIC,TightlyAustralia,-Coupled1991.Multiprocessor.PhD

[222]RonaldD.Pose.Password-Capabilities:TheirEvolutionfromthePassword-
CapabilitySystemandBeyond.AustralianComputerScienceCommunica-
2001.January23(4):105–113,,tions

[223]DavidL.Presotto.InfernoSecurity.InProceedingsofthe42ndIEEEInter-
nationalComputerConferenceCOMPCON97,pages251–254,SanJose,CA,
USA,February1997.IEEEComputerSocietyPress,LosAlamitos,CA,USA.

[224]Kthesis,otagiriMonashRamamohanarao.University,AClayton,NewModelVIC,forAustralia,JobMana1980.gementSystems.PhD

[225]tion.BrianRandell.CommunicationsANoteofontheStorageACM,12(7):365–369,FragmentationandJuly1969.ProgramSegmenta-

[226]BrianRandellandJ.N.Buxton,editors.SoftwareEngineeringTechniques:
ReportonaConferencesponsoredbytheNATOScienceCommittee,Rome,
Italy,October1969.Petrocelli/Charter,NewYork,NY,USA.

[227]workRichardF.OperatingRashid.System.FromInRIGtoProceedingsAccentoftotheFaMach:llJointTheComputerEvolutionofConferenceaNet-,
Press,pagesLos1128–1137,Alamitos,CDallas,A,USA.TX,USA,November1986.IEEEComputerSociety

[228]RichardF.Rashid,DanielP.Julin,DouglasB.Orr,RichardSanzi,RobertV.
Baron,AlessandroForin,DavidB.Golub,andMichaelB.Jones.Mach:A
SystemSoftwareKernel.InProceedingsofthe1989IEEEInternationalCon-
ference,COMPCON,pages176–178,SanFrancisco,CA,USA,1989.IEEE
ComputerSocietyPress,LosAlamitos,CA,USA.

[229]RobbertvanRenesse,HansvanStaveren,andAndrewS.Tanenbaum.The
PerformanceoftheAmoebaDistributedOperatingSystem.Software–Prac-
tice&Experience,19(3):223–234,March1989.

266

Bibliography

[230]IanGregoryRichards.TheOrganizationandProtectionofInformationina
ComputerUtility.PhDthesis,MonashUniversity,Clayton,VIC,Australia,
1981.[231]BruceL.Riddle,MurayS.Miron,andJudithA.Semo.PasswordsinUseina
UniversityTimesharingEnvironment.Computers&Security,8(7):569–578,
1989.[232]DennisM.RitchieandKenThompson.TheUNIXTime-SharingSystem.
CommunicationsoftheACM,17(7):365–375,July1974.
[233]DennisM.Ritchie.TheEvolutionoftheUnixTime-sharingSystem.In
ProceedingsoftheSymposiumonLanguageDesignandProgrammingMethod-
ology,volume79ofLectureNotesinComputerScience,pages25–36,Sydney,
NSW,Australia,September1979.Springer-Verlag,Heidelberg,Germany.
[234]DennisM.Ritchie.ReflectionsonSoftwareResearch.Communicationsof
theACM,27(8):758–760,August1984.
[235]LawrenceG.Roberts.MultipleComputerNetworksandIntercomputerCom-
munication.InProceedingsoftheFirstACMSymposiumonOperatingSystem
Principles,pages3.1–3.6,Gatlinburg,TN,USA,October1967.ACMPress,
NewYork,NY,USA.
[236]JohnRosenbergandJ.LeslieKeedy.TheMONADSHardwareKernel.In
ProceedingsoftheEighthAustralianComputerConference,volume4,pages
1542–1552,Canberra,ACT,Australia,1978.
[237]JohnRosenberg.TheConceptofaHardwareKernelanditsImplementation
onaMinicomputer.PhDthesis,MonashUniversity,Clayton,VIC,Australia,
1979.[238]JohnRosenbergandJ.LeslieKeedy.SoftwareManagementofaLargeVir-
tualMemory.InProceedingsoftheFourthAustralianComputerScienceCon-
ference,pages173–181,Brisbane,QLD,Australia,1981.
[239]JohnRosenbergandDavidA.Abramson.MONADS-PC–ACapability-Based
WorkstationtoSupportSoftwareEngineering.InProceedingsofthe18th
HawaiiInternationalConferenceonSystemSciences,pages222–231,Hon-
1985.JanuaryUSA,HI,olulu,[240]JohnRosenbergandJ.LeslieKeedy.ObjectManagementandAddressing
intheMONADSArchitecture.InProceedingsoftheSecondInternational
WorkshoponPersistentObjectSystems,Appin,Scotland,UK,August1987.
[241]JohnRosenberg,DavidM.Koch,andJ.LeslieKeedy.AMassiveMemory
Supercomputer.InProceedingsofthe22ndHawaiiInternationalConference
onSystemSciences,pages338–345,Kailua-Kona,HI,USA,January1989.

Bibliography

267

[242]JohnRosenberg,AlanDearle,DavidHulse,AndersLindström,andStephen
Norris.OperatingSystemSupportforPersistantandRecoverableComputa-
tions.CommunicationsoftheACM,39(9):62–69,September1996.
[243]AlvaroSalla,RolandWolf,andGustavoGonzalez.System/390MVS/ESA
Version5WorkloadManagerPerformanceStudies.NumberSG24-4352-00in
IBMRedbooks.InternationalTechnicalSupportOrganisation,IBMCorpora-
tion,Poughkeepsie,NY,USA,September1995.
[244]JeromeH.SaltzerandMichaelD.Schroeder.TheProtectionofInformation
inComputerSystems.InProceedingsoftheIEEE,volume63(9),pages1278–
1975.September1308,[245]JulianSatran,KalmanMeth,CostaSapuntzakis,MallikarjunChadalapaka,
andEfriZeidner.iSCSI.InternetDraftdraft-ietf-ips-iscsi-20,InternetEn-
gineeringTaskForce,WorkingGrouponIPStorage,January2003.URL:
.-ips-iscsi20.org/internet-drafts/draft-ietf.ietfhttp://www[246]AxelSchmolitzkyandPeterBrössler.MONADS-PascalSprachbeschreibung.
InternalReport,UniversityofUlm,Germany,June1995.
[247]AxelSchmolitzky.EinModellzurTrennungvonVererbungundTypabstraktion
inobjektorientiertenSprachen.PhDthesis,UniversityofUlm,Ulm,Germany,
1999.April[248]FredB.Schneider.LeastPrivilegeandMore.IEEESecurityandPrivacy,
2003.September1(3):55–59,[249]BruceSchneier.AppliedCryptography.JohnWiley&Sons,NewYork,NY,
1996.Januaryedition,secondUSA,[250]MichaelL.Scott,ThomasJ.LeBlanc,BrianD.Marsh,TimothyG.Becker,
CezaryDubnicki,EvangelosP.Markatos,andNeilG.Smithline.Implement-
ationIssuesforthePsycheMultiprocessorOperatingSystem.Computing
1989.3(1):101–138,,Systems[251]SecureComputingCorporation.DTOSGeneralSystemSecurityandAs-
surabilityAssessmentReport.TechnicalReportDTOSCDRLA011,Secure
ComputingCorporation,Roseville,MN,USA,1997.
[252]SecureComputingCorporation.DTOSLessonsLearnedReport.Technical
ReportDTOSCDRLA008,SecureComputingCorporation,Roseville,MN,
1997.USA,[253]SecureComputingCorporation.AssuranceintheFlukeMicrokernel:Fi-
nalReport.TechnicalReportCDRLA002,SecureComputingCorporation,
Roseville,MN,USA,April1999.

268

Bibliography

[254]SecureComputingCorporation.AssuranceintheFlukeMicrokernel:Formal
SecurityPolicyModel.TechnicalReportCDRLA003,SecureComputing
Corporation,Roseville,MN,USA,February1999.

[255]SecureComputingCorporation.AssuranceintheFlukeMicrokernel:Formal
TopLevelSpecification.TechnicalReportCDRLA004,SecureComputing
Corporation,Roseville,MN,USA,February1999.

[256]intheJonathanEROSS.Shapiro,Kernel–DavidJ.ImplementingFarber,andEfficientJonathanM.OrthogonalSmith.StatePersistenceCachingina
onPurePersistentCapabilityObjectSystem.SystemsIn,CapeProceedingsMay,ofNJ,theUSA,Seventh1996.InternationalWorkshop

[257]ity.TJonathanechnicalS.RShapiroeportandMS-CIS-97-26,SamuelWeber.VDepartmenterifyingofOperatingComputerandSystemInfoSermcur-a-
tionScience,UniversityofPennsylvania,Philadelphia,PA,USA,1997.

[258]PJonathanennsylvania,S.Shapiro.Philadelphia,EROS:PA,AUSA,Capability1999.System.PhDthesis,Universityof

[259]JonathanMechanism.S.InShapiroProceedingsandofSamueltheW2000eber.IEEEVerifyingSymposiumtheonEROSSecurityConfineandmePri-nt
vacyPress,,LospagesAlamitos,166–176,CA,BerkeleyUSA.,CA,USA,May2000.IEEEComputerSociety

[260]ingsJonathanoftheS.2003Shapiro.IEEEVSymposiumulnerabilitiesoninSecuritySynchronousandIPCPrivacy,Designs.pagesIn251–262,Proceed-
Oakland,CA,USA,May2003.

[261]Addison-AbrahamWesley,SilberschatzReading,andMA,PeterUSA,B.fourthGalvin.edition,Operating1994.SystemConcepts.

[262]PEdowerPCSilha,UserCathyMayInstruction,andSetBradFrey.ArchitectureP.owerPCInternationalArchitectureBook,BusinessBookMa-I:
chinesCorporation,Austin,TX,USA,September2003.AvailableatURL:
..ibm.com/developerworks/eserver/pdfs/archpub1.pdfhttp://www

[263]PEdowerPCSilha,VCathyirtualMay,EnvironmentandBradFrey.ArchitectureP.owerPCInternationalArchitectureBook,BusinessBookMa-II:
chinesCorporation,Austin,TX,USA,December2003.AvailableatURL:
..ibm.com/developerworks/eserver/pdfs/archpub2.pdfhttp://www

[264]PEdowerPCSilha,CathyOperatingMay,andEnvironmentBradFrey.ArchitecturePowerPC.ArchitectureInternationalBook,BusinessBookMa-III:
chinesCorporation,Austin,TX,USA,December2003.AvailableatURL:
..ibm.com/developerworks/eserver/pdfs/archpub3.pdfhttp://www

Bibliography

269

[265]EspenSkoglund,ChristianCeelen,andJochenLiedtke.TransparentOrtho-
gonalCheckpointingthroughUser-LevelPagers.InProceedingsoftheNinth
InternationalWorkshoponPersistentObjectSystems,pages201–214,Lille-
hammer,Norway,September2000.Springer-Verlag,Heidelberg,Germany.
[266]FrankG.Soltis.InsidetheAS/400.DukePress,Loveland,CO,USA,1996.
[267]RaySpencer,StephenSmalley,PeterLoscocco,MikeHibler,DavidAnder-
sen,andJayLepreau.TheFlaskSecurityArchitecture:SystemSupport
forDiverseSecurityPolicies.InProceedingsoftheEighthUSENIXSecurity
Symposium,pages123–139,Washington,DC,USA,August1999.USENIX
Association,Berkeley,CA,USA.
[268]OlafSpinczyk.AspektorientierungundProgrammfamilienimBetriebssystem-
bau.PhDthesis,Otto-von-Guericke-UniversitätMagdeburg,Magdeburg,
2002.December,Germany[269]RajSrinivasan.RPC:RemoteProcedureCallProtocolSpecificationVer-
sion2.NetworkWorkingGroupRequestsforCommentsRFC1831,Sun
1995.Microsystems,[270]MaartenvanSteen,PhilipHomburg,andAndrewS.Tanenbaum.Globe:
AWide-AreaDistributedSystem.IEEEConcurrency,7(1):70–78,January
1999.[271]SunMicrosystems.EnterpriseJavaBeansSpecification,Version2.1.Sun
Microsystems,Inc.,SantaClara,CA,USA,November2003.
[272]MichaelSwift,StevenMartin,HenryM.Levy,andSusanJ.Eggers.Nooks:
AnArchitectureforReliableDeviceDrivers.InProceedingsoftheTenth
ACMSIGOPSEuropeanWorkshop,pages101–107,Saint-Emilion,France,
September2002.ACMPress,NewYork,NY,USA.
[273]ClemensA.Szyperski.ComponentSoftware:BeyondObject-OrientedPro-
gramming.Addison-Wesley,Reading,MA,USA,firstedition,1999.
[274]AndrewS.TanenbaumandSapeJ.Mullender.Amoeba–ACapability-Based
DistributedOperatingSystem.InProceedingsoftheOn-LineConferenceon
LocalNetworksandDistributedOfficeSystems,pages363–377,London,UK,
1981.May[275]AndrewS.TanenbaumandSapeJ.Mullender.TheDesignofaCapability-
BasedDistributedOperatingSystem.TechnicalReportIR-88,VrijeUni-
1984.NovemberNetherlands,Amsterdam,versiteit[276]AndrewS.Tanenbaum,SapeJ.Mullender,andRobbertvanRenesse.Using
SparseCapabilitiesinaDistributedOperatingSystem.InProceedingsof

270

Bibliography

theSixthInternationalConferenceonDistributedComputingSystems,pages
558–563,Cambridge,MA,USA,May1986.IEEEComputerSocietyPress,
USA.A,CAlamitos,Los[277]AndrewS.Tanenbaum,RobbertvanRenesse,HansvanStaveren,GregoryJ.
Sharp,andSapeJ.Mullender.ExperienceswiththeAmoebaDistributed
OperatingSystem.CommunicationsoftheACM,33(12):46–63,December
1990.[278]AndrewS.Tanenbaum.ModernOperatingSystems.Prentice-Hall,Engle-
1992.USA,NJ,Cliffs,wood[279]AndrewS.Tanenbaum.AComparisonofThreeMicrokernels.Journalof
1995.9(1/2):7–22,,Supercomputing[280]AvadisTevanian,Jr.Architecture-IndependentVirtualMemoryManagement
forParallelandDistributedEnvironments:TheMachApproach.PhDthesis,
DepartmentofComputerScience,CarnegieMellonUniversity,Pittsburgh,
1987.DecemberUSA,A,P[281]CharlesP.Thacker,EdwardM.McCreight,ButlerW.Lampson,RobertF.
Sproull,andDavidR.Boggs.Alto:APersonalComputer.TechnicalReport
CSL-79-11,XeroxPaloAltoResearchCenter,PaloAlto,CA,USA,August
1979.[282]KenThompson.UNIXImplementation.BellSystemTechnicalJournal,
1978.57(6):1931–1946,[283]KenThompson.ReflectionsonTrustingTrust.CommunicationsoftheACM,
1984.August27(8):761–763,[284]JohnVernonThomson.TheDesignofaFlexibleOperatingSystemfora
Capability-BasedComputer.PhDthesis,MonashUniversity,Clayton,VIC,
1984.Australia,[285]TrustedComputingGroup.MainSpecificationVersion1.1b.TrustedCom-
putingGroup,Inc.,Portland,OR,USA,2003.
[286]PatrickA.TullmannandJayLepreau.NestedJavaProcesses:OSStructure
forMobileCode.InProceedingsoftheEighthACMSIGOPSEuropeanWork-
shoponSupportforComposingDistributedApplications,pages111–117,Sin-
tra,Portugal,September1998.ACMPress,NewYork,NY,USA.
[287]PatrickA.Tullmann.TheAltaOperatingSystem.Master’sthesis,Depart-
mentofComputerScience,UniversityofUtah,SaltLakeCity,UT,USA,
1999.December

Bibliography

271

[288]KevinT.VanMaren.TheFlukeDeviceDriverFramework.Master’sthesis,
DepartmentofComputerScience,UniversityofUtah,SaltLakeCity,UT,
1999.DecemberUSA,[289]FrancisVaughan,AlanDearle,JiannongCao,RexdiBona,JamesMatthew
Farrow,FransA.Henskens,AndersLindström,andJohnRosenberg.Caus-
alityConsiderationsinDistributedPerststentOperatingSystems.InPro-
ceedingsofthe17thAnnualComputerScienceConference,pages409–420,
1994.JanuaryZealand,NewChristchurch,[290]JohnViegaandGaryMcGraw.BuildingSecureSoftware—HowtoAvoidSe-
curityProblemstheRightWay.Addison-Wesley,Reading,MA,USA,Septem-
2002.ber[291]JeroenDoronVochteloo.Design,ImplementationandPerformanceofPro-
tectionintheMungiSingleAddressSpaceOperatingSystem.PhDthesis,
SchoolofComputerScienceandEngineering,UniversityofNewSouth
Wales,Sydney,NSW,Australia,1998.
[292]RobertWahbe,StevenLucco,ThomasE.Anderson,andSusanL.Graham.
EfficientSoftware-BasedFaultIsolation.InProceedingsofthe14thACM
SymposiumonOperatingSystemPrinciples,pages203–216,Asheville,NC,
USA,December1993.ACMPress,NewYork,NY,USA.
[293]ChrisS.Wallace.MemoryandAddressingExtensionstoaHP2100A.In
ProceedingsoftheEighthAustralianComputerConference,volume4,pages
1796–1811,Canberra,ACT,Australia,1978.
[294]ChrisS.Wallace.PhysicallyRandomGenerator.ComputerSystemsScience&
1990.5(2):82–88,,Engineering[295]ChrisS.Wallace.CharginginaSecureEnvironment.InProceedingsof
theInternationalWorkshoponComputerArchitecturetoSupportSecurityand
PersistenceofInformation,WorkshopsinComputing,pages85–96,Bremen,
Germany,May1990.Springer-Verlag,Heidelberg,Germany.
[296]MichaelWallner.Personalcommunication,February2004.
[297]DavidL.WeaverandTomGermond.TheSPARCArchitectureManual,Ver-
sion9.SPARCInternational,Inc.,SantaClara,CA,USA,2000.URL:
.http://developers.sun.com/solaris/articles/sparcv9.pdf[298]MoritzWende,MichaelSchöttner,RalphGöckelmann,TobiasBindhammer,
andPeterSchulthess.PerformanceEvaluationofaTransactionalDSMSys-
tem.InProceedingsoftheEighthInternationalConferenceonParalleland
DistributedProcessingTechniquesandApplications,pages97–106,LasVegas,
NV,USA,June2002.CSREAPress.

272

Bibliography

[299]DavidA.Wheeler.SLOCCount:AsetoftoolsforcountingphysicalSource
LinesofCode(SLOC)inalargenumberoflanguagesofapotentiallylarge
setofprograms,2001.DocumentationandsourcecodeavailableatURL:
..com/sloccount/.dwheelerhttp://www[300]MauriceV.WilkesandRogerM.Needham.TheCambridgeCAPComputer
anditsOperatingSystem.NorthHolland,Amsterdam,Netherlands,Oxford,
1979.UK,[301]MauriceV.Wilkes.HardwareSupportforMemoryProtection:CapabilityIm-
plementations.InProceedingsoftheSymposiumonArchitecturalSupportfor
ProgrammingLanguagesandOperatingSystems,pages107–116,PaloAlto,
1982.MarchUSA,A,C[302]MauriceV.Wilkes.SecurityManagementandProtection—APersonalAp-
proach.TheComputerJournal,27(1):3–7,February1984.
[303]NiklausWirth.TheProgrammingLanguageOberon.Software–Practice&
1988.July18(7):671–690,,Experience[304]WorldWideWebConsortium.SOAPVersion1.2Part1:MessagingFrame-
work.MassachusettsInstituteofTechnology,Cambridge,MA,USA,June
2003.URL:http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.
[305]WorldWideWebConsortium.SOAPVersion1.2Part2:Adjuncts.Mas-
sachusettsInstituteofTechnology,Cambridge,MA,USA,June2003.URL:
.-soap12-part2-20030624/.w3.org/TR/2003/REChttp://www[306]WilliamA.Wulf,EllisS.Cohen,WilliamM.Corwin,AnitaK.Jones,Roy
Levin,C.Pierson,andFredJ.Pollack.HYDRA:TheKernelofaMultipro-
cessorOperatingSystem.CommunicationsoftheACM,17(6):336–345,June
1974.[307]WilliamA.Wulf,RoyLevin,andC.Pierson.OverviewoftheHYDRAOperat-
ingSystemDevelopment.InProceedingsoftheFifthSymposiumonOperating
SystemPrinciples,pages122–131,Austin,TX,USA,November1975.ACM
Press,NewYork,NY,USA.
[308]WilliamA.Wulf,RoyLevin,andSamuelP.Harbison.HYDRA/C.mmp:An
ExperimentalComputerSystem.McGraw-Hill,NewYork,NY,USA,1981.
[309]BenjaminZornandDirkGrunwald.EmpiricalMeasurementsofSixAlloca-
tion-intensiveCPrograms.TechnicalReportCU-CS-604-92,Universityof
ColoradoatBoulder,Boulder,CO,USA,June1992.

Danksagung

273

BeiderErstellungdieserArbeitspieltenvielePersoneneinewichtigeRolle.Zualler-
erstIdeenzudankeichdiskutieren,meinemdieichDoktorvaterlange,ZeitLesKselbsteedy,nichtderrichtigimmerbereitverstand.war,SeinmeineVertrauenneuen
seinundseineendloserGeduldStromhalfenimkonstruktiverAnfangsstadiumKritikdazu,dieserdieKArbeitonzeptesehr.prägnantSpäterundzwangpräzisemich
auszuarbeiten.IchdankeebensodenanderenGutachtern,JörgKaiserundJohn
Rosenberg.JohnRosenberghatdieFertigstellungdieserArbeitstarkbeschleunigt,
indemereinenAbgabeterminvorschlug.WiebeijedemgrößerenProjektwurde
derTMeineerminKollegenüberschritten,inderaberAbteilungeinenRzuhaben,echnerstrukturenstelltedieboteneinePrioritätenklarangenehme.und
ner,inspirierendeCarlosMitidieriArbeitsumgebung.undHubertGiselaPiontekMengerwaren,immerChristianoffenHeinlein,füreineMichaelDiskussionWall-
VoderoraussetzungUnterhaltung.fürdenDieerfolgreichengegenseitigeAbschlußUnterstützungdieserundArbeit.ErmutigungGiselaMengerwarenundeine
vieleChristianhilfreicheHeinleinKommentarehabenfreiwilligundVmeineorschlägeArbeitbei.korrekturgelesenundsteuerten
DieFinanzierungAbteilungmeinerRFechnerstrukturenorschung,aninklusivederReisenUniversitätundUlmAusrüstung.botIchUnterstützungmöchtedenund
PersonenderzeitigenderundFakultätfrüherenfürInformatikMitarbeiternfürderihreAbteilungHilfeRdanken.echnerstrukturenundvielen
IchsollteauchRonaldPose,FransHenskensundMichaelHannaforddanken,die
währendihrerBesucheinUlmundwährendmeinerBesucheinAustralienwertvol-
leDiskussionspartnerwaren.IhreandereSichtweiseundihrandererHintergrund
halfenVielemir,anderedieKPersonenernpunktemeinesbeeinflusstendenEntwurfsansatzesFortschrittzudieserbestimmen.Arbeitaufdieeine
waroder.SpeziellandereWschuldeeise.IchichdendankeihnenEntwicklernallen,desganzLinuxgleichext3wiezufällig-DateisystemsihreinBeitragvir-
imtuellesJournal.BierfürDiesdiehateinestandardmäßigeerheblichenTeilSpeicherungmeinerdesArbeitgesamtengerettet,Inhaltsderderverlorenge-Dateien
gangenNichtwäre,zuletztwenndankenurichdiemeinenEltern,Strukturinformationendiemichbeiallemaktualisiertwordenunterstützten.wären.

274

Acknowledgements

Therearealargenumberofpeoplewhoplayedanimportantroleinthecreation
ofthisthesis.Firstandforemost,Ithankmyadvisor,LesKeedy,whowasalways
willingtodiscussmynewideasthatforalongtimeevenIdidnotunderstand
Laterproperlyhis.Hisnevertrustendingandstreampatienceofhelpedconstructivegreatlyincriticismtheforcedearlymephasetoofthiselaboratethesis.the
JohnconceptsRosenbconciselyerg.JohnandRpreciselyosenberg.Ispedalsoupthankthethecompletionotherofexaminers,thisthesisJörgKaiserconsiderablyand
bysuggestingadeadline.Likeinanysubstantialprojectthedeadlinewasmissed,
buthavingoneatallstraightenedthepriorities.
andMyinspiringcolleaguesatenvironment.theDepartmentGiselaofMenger,ComputerChristianStructuresHeinlein,providedMichaelaWfriendlyallner,
CarlosMitidieriandHubertPiontekwerealwaysopenforadiscussionorachat.
Thecompletionmutualofthissupportthesis.andandGiselaMengerencouragementandwereChristianaHeinleinprerequisitehavefortheproofreadsuccessfulthis
thesisThevoluntarilyDepartmentandofComputercontributedmanyStructureshelpfulatthecommentsUniversityandofUlmsuggestions.providedsup-
theportstaffand,pastfundingandforpresent,myatresearch,theincludingDepartmenttripsofandComputerequipment.structuresIwantandtonumer-thank
ousIshouldpeopleatalsotheFthankacultyRofonaldPose,InformaticsFransforallHenskenstheirhelp.andMichaelHannafordwho
werevaluablediscussionpartnersduringtheirvisitstoUlmandduringmyvisits
toAustralia.Theirdifferentperspectiveandbackgroundhelpedmeidentifyingthe
keyitemsinmydesignapproach.
IthankManyallotherofthem,peoplenomatterinfluencedhowtheaccidentalprogressoftheirthisthesiscontributioninonewas.wayInorparticularanother.
IowethedevelopersoftheLinuxext3filesystemavirtualbeerforincludingthe
completefilecontentinthejournalbydefault.Itsavedasubstantialamountofmy
workLastbutwhichnotwouldleastIhavethankbeenmylostifparentsonlyfortheecouragingmetadatamewouldathaveeverything.beenupdated.

1998–1993z.Z.–1998

UngeprüftewissenschaftlicheHilfskraftanderUniversitätUlm
WissenschaftlicherAngestellteranderUniversitätUlm,Abtei-
echnerstrukturenRlung

Berufstätigkeit

InformatikstudiumanderUniversitätUlm,AbschlußDiplom-
InformatikerAbschlußAuslandsstudiumBacheloranofderComputerUniversityScienceofW(Honours)ollongong,Australien,
PromotionsstudiumanderUniversitätUlm,FakultätfürInfor-
matik

Studium1998–19911996–19952003z.Z.–

1982–19781991–1982

GrundschuleanderGrund-undHauptschuleWarthausen
Wieland-GymnasiumBiberacha.d.RißundTechnischesGym-
nasiumBiberacha.d.Riß,AbschlußAllgemeineHochschulreife

Schulbildung

EspenlaubKlausName:Geburtsort:Geburtsdatum:30.BiberachJuni1972a.d.Riß
klaus@espenlaub.comE-Mail:

PAngabenersönliche

Lebenslauf

275

276

VitaeCurriculum

DetailsersonalP

KlausName:EspenlaubDateofbirth:30thJune1972
PlaceE-mail:ofbirth:Biberach/Riß,klaus@espenlaub.comGermany

ExperienceProfessional

since1998ResearchAssistantattheUniversityofUlm,Departmentof
StructuresComputer1993–1998StudentAssistantattheUniversityofUlm,DepartmentofCom-
Structuresputer

EducationUniversity

since2003PhDstudentattheUniversityofUlm,FacultyofInformatics
1995–1996versityDegreeofW“Bachelorollongong,ofComputerAustraliaScience(Honours)”attheUni-
1991–1998Degree“Diplom-Informatiker”attheUniversityofUlm

EducationSchool

1991–1988

1982–1978

HighnischesSchoolGymnasiumatWieland-GymnasiumBiberach/Riß,generalBiberach/RißqualificationandTech-for
entranceuniversityPrimarySchoolatGrund-undHauptschuleWarthausen

Un pour Un
Permettre à tous d'accéder à la lecture
Pour chaque accès à la bibliothèque, YouScribe donne un accès à une personne dans le besoin