Transcript Objectives of KeyKOS

Microkernels
How to build a dependable, modular
and secure operating system?
Goals of Lecture
 to show that operating system can be
divided into sets of abstractions,
mechanisms and policies
 to explain the alternative way an operating
system can be built
 to present main design issues of KeyKOS
microkernel
Structure of Lecture
 introduction to microkernel technology
 comparison of monolithic OS with
microkernel based OS
 description of KeyKOS microkernel
Concept of Microkernel
 the idea dates back to 1969 when was
introduced by Per Brinch Hansen
 alternative approach to operating system
construction
 attempt to make operating systems more
modular, more extendable, more secure and
more reliable
Monolithic Operating System
 kernel of monolithic operating system
provides high-level abstractions and realises
sophisticated resource scheduling policies
 as kernel does too many things, it tends to
be large and unreliable
 additionally, monolithic OS cannot evolve
over time to meet new requirements
Microkernel Approach
 microkernel implements only small set of
simple abstractions and mechanisms
 higher level abstraction and services are
provided by ordinary sequential processes
 the computing environment is created by
co-operating processes
Advantages of Microkernel
 various parts of OS can be designed,
implemented, tested and executed
independently
 as components of OS and their mutual
relations can change over time, the
evolution is easy to take place
 more operating systems can run on top of
microkernel simultaneously
Disadvantages of Microkernels
 as most of services are provided by
computational processes, there are much
more context switches and larger
communication overhead compared to
monolithic OS
KeyKOS
The nanokernel architecture
Objectives of KeyKOS
 To solve the security, data sharing, pricing,
reliability and extensibility requirements of
a commercial computer service in a network
environment
History of KeyKOS




1972
1974
1976
1979
written description
development funding
first terminal message
public presentation
Architectural Foundations
 Stateless kernel
 Single-level store
 Capabilities
Stateless Kernel
 the system outside the microkernel is
completely described by contents of pages
and nodes, which are persistent
 all microkernel state can be derived after
system crash or power outage
 memory functions merely as a disk cache
Single-Level Persistent Store
 applications, like memory pages, are
persistent
 data consistency is guaranteed by making
periodic checkpoint
 persistence is rule, not exception
Objects and Capabilities
 every object in the system is exclusively
referred to by one or more capabilities
 capability gives its holder the authority to
request a service from object it names;
object has no intrinsic authority
 messages are the only form of interaction
between objects
Computing Model
 it is worth to view microkernel as a virtual
machine which provides objects with
communication capability and primitive
objects
 further, the notion of isolated application
can be replaced by the paradigm of cooperating components
Primitive Objects
 all state information in the system is stored
in two types of primitive objects


pages which can store data
nodes which can store capabilities
 primitive objects are persistent
 it follows that any non-primitive object in
the system is persistent as well
Fundamental Objects
 objects built from one or more nodes and/or
pages and interpreted by the kernel itself



domains provide an environment in which
process can execute
segments define a portion of memory storage
meters control and measure computer resources
Computing Issues
 all policy issues are removed from kernel by
introducing the concept of keepers



domain keeper
segment keeper
meter keeper
Security Issues
 we cannot always anticipate the security
policies which will be needed in the future
 it proves useful to separate security
(policies) from protection (mechanisms)
 system should obey the Principle of Least
Authority