CMSC 838Y Paper Reviews

Skip down to paper 0: Brian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, David Becker, Marc Fiuczynski, Craig Chambers, and Susan Eggers. Extensibility, safety, and performance in the SPIN operating system. In Proceedings of the 15th ACM Symposium on Operating System Principles, pages 267-284, Copper Mountain Resort, Colorado, 1995. [ .ps ]

Reviews for paper 0

Review from Yuan Yuan<yuanyuan@cs> at Mon Feb 17 22:15:21 EST 2003:

This paper gives a complete view of extensible operating system SPIN by 
addressing its motivation, involved techniques and performance.  By provide a 
specifiable base system, SPIN allows applications to customize the underlying 
services dynamically to satisfy their needs and improve performance. The key of 
SPIN system architecture is the method of combining applications¡¯ extension 
with the system safely, so that efficient, fine-grained control over resources 
and communication becomes applicable. Also a set of core services are provided 
by SPIN to manage memory and processor resources and exported with fine-grained 
interfaces for application to adapt. SPIN and its extensions are written in 
Modula-3 language to enforce type safety and protect kernel from extensions. In 
the end of this paper, performance of SPIN is explained from many perspectives. 
From all the result, we can see extensible operating system presents 
competitive performance for letting applications to tailor the system services.

The paper is valuable since it summarized the key technology involved in SPIN 
and evaluated it by doing variety of testing. Good thing is making possible for 
applications to define the system service they need. Bad thing is the safety 
and performance problems. SPIN system solves it by depending co-location 
mechanism, language level protection and etc. But I doubt whether it can 
eliminate authorized malicious code to grab resources and execute without 

Review from Bryan Payne <bdpayne@cs> at Tue Feb 18 13:53:47 EST 2003:

(note: my postscript viewer would not display page 13 of this paper)

This paper provides an introduction to SPIN.  The format of the paper was very 
typical for an implementation paper, however I still found that the text was 
difficult to follow at times.  The main concept behind SPIN is to allow for 
operating system extensibility with minimal cost, where cost relates to a 
variety of factors including the execution speed, executable size, and type 
safety within the extensions.  Using these extensions, one can blur the line 
between kernel and user space in order to allow for a larger degree of 
flexibily for each type of program (e.g., a web server can use it's own file 
caching scheme in order to provide for optimal reponse times).

I find this idea to be very appealing from a programmers perspective in that it 
would allow user applications to have a much higher level of system control.  
Certainly there are a wide variety of applications that could benefit from 
this.  However, I feel that there are also a variety of security concerns that 
arrise with this type of system (e.g., Since a capability is equivilent to a 
pointer, what would prevent someone from forging a pointer?).  While this paper 
was in no way trying to be a security paper, I feel that the security issues 
would ultimately need to be addressed before such an operating system could 
achieve real world viability.  Beyond the security concerns, I generally liked 
the approach presented in this paper.

Review from Nikhil Swamy <nswamy@cs> at Wed Feb 19 20:23:07 EST 2003:

  This paper by Barshad et al provides an overview of the design and 
implementation of the SPIN operating system. SPIN uses an event-based model to 
achieve a loose coupling between interacting modules. The idea is to provide an 
efficient yet safe means of extending the services provided by the OS. 

  In addressing the safety issue, the authors chose to leverage the features of 
Modula-3 that allow the programmer to explicitly limit access (hiding) to 
features of a module. The Modula-3 compiler can also ensure that usage and 
extensions of modules obey the type checking rules thereby providing a degree 
of safety. The authors resign the discussion of a higher-level notion of 
safety/enforcement of semantic contracts etc. to a brief mention of guards and 
an authorization model. That said, the asynchronous model of dispatch and a 
layered approach to the construction of the event-based extensions seems to 
satisfy the requirement that the consequences of any such violation is 
restricted to a limited hierarchy of components.

  The main feature of SPIN that provides efficiency is colocation of extension 
code within the kernel address space. This allows application specific behavior 
be provided at the expense of only an in-kernel procedure call. While other 
models of extensibility provide some safety by restricting access across 
address-spaces, SPIN relies on Modula-3's dynamic linking, type checking and 
encapsulation facilities to ensure safe interaction between user extension and 
the kernel. As such, SPIN seems like a variant of the Pilot system described 
briefly. While the
authors point out that the SPIN uses a hybrid approach of virtual address 
spaces with language features for protection, their case is weakened by the 
fact that
in the examples/benchmarks presented all the extensions are colocated with the 
kernel. Furthermore, little space is devoted to scalability and the argument 
that the principal bottleneck in the processing of multiple handlers is only 
the dispatcher is unconvincing.

Review from Prashant Lamba<> at Thu Feb 20 02:28:07 EST 2003:

This paper describes the architecture and performance of SPIN, which is an 
extensible operating system. According to the paper extensions allow an 
application to specialize the underlying operating system to achieve 
performance and functionality. This paper highlights the point of developing 
SPIN operating System that provides extensibility, safety and good performance. 
SPIN uses four techniques co-location, enforced modularity, logical protection 
domains and dynamic call binding of languages. Paper describes the need of 
language features to used for SPIN OS .The traditional OS are not well suited 
for specialization and good performance. The paper also gives the brief 
overview of some of the systems like Hydra, use of micro kernel for building 
extensible system, and aegis. And author points out the disadvantages of the 
earlier systems.
The design of the SPIN depends on the language’s safety and encapsulation like 
interfaces, type safety and automatic storage management. Later part of the 
paper explains the concept of protection model i.e. set of operations that can 
be applied to resources. In this portion of the paper Authors explains the 
concept of the capabilities and very well outshines the method implemented in 
traditional OS i.e. using hardware with the method of implementing it with 
pointers in SPIN. In SPIN the naming and protection interface is at the level 
of language not at the virtual memory level. The extension model is based on 
the events.
The paper also throws a light on the some of the core services implementation 
in SPIN, like Extensible memory management and Extensible thread management. 
The paper presents the concept where the core services are trusted i.e. they 
must be executed according to there specifications in the interfaces.In the end 
of the paper system performance issues are touched .The performance of SPIN is 
evaluated from four prospective: System Size, Microbenchmarks, Networking and 
End-to-end performance.

Review from Brian Krznarich bjkrz@cs at Thu Feb 20 08:11:17 EST 2003:

This paper gives an overview of the SPIN OS.  The goal of SPIN was/is to have 
an OS where system services can be efficiently tuned to Application 
requirements in a standard way.  The authors note that all OSs are extensible 
to some degree, but in general such extensibility at run time comes with high 
overhead costs- with the alternative being kernel modification and 
recompiation.  A problem is that OSs typically try to provide the most 
generally useful optimizations which may not be correct for all applications.

SPIN's approach is to allow extensions to be added on to the system at runtime. 
 The extensions handle specific fine grained events which are explicitly 
exported by the OS.  Extensions are linked into kernel address space where they 
can be accessed in general with the speed of a function call.  

Safety is attained through "Enforced modularity" of the language used: 
modula-3.  The OS itself and all OS extensions must be implemented in this 
language, and in turn teh OS relies heavily on the compiler to verify the 
safety of generated code.  In addition there is load time type checking of 
registered handlers and guards to ensure expected behavior.  Since handlers run 
in kernel space safety verification is important. While I believe that code 
generated by a trusted compiler can be in turn trusted by the system, it is not 
clear to me that a malicious compiler could not generate code to corrupt the 
system, or that a user in general could not generate code by means other than a 
trusted compiler to do the same.  Perhaps this safety is inherantly checked 
within the compiles modules?  

The model of the OS is that of events and event handlers, where new handlers 
are the extentsions.  Multiple handlers may be registered for a single event, 
and each handler may have  a series of guards which determine for any event 
whether a corresponding handler should actually be invoked.  Because handlers 
get fine grained access to low level system events, special purpose event 
handling can be implemented more efficiently than in traditional OSes.  An 
example given is that of a  video application which streams packets directly to 
a video framebuffer.  A handler can move data directly from the the packet to 
the buffer, avoiding the multiple data copies and kernal calls usually present 
to move network data. 

Benchmarks suggest that these optimations are generally very effective ;)

Review from Polyvios Pratikakis <polyvios@cs> at Thu Feb 20 09:33:55 EST 2003:

The SPIN operating system is presented in this paper. Initially, after a small 
introduction on OS extensibility necessity, previous efforts to achieve 
extensibility are presented. Following, there is an introduction to the 
architecture of SPIN, and it's main feature is presented, it's protection model 
through which extensibility is achieved. SPIN uses the type-safety of the 
Modula-3 language to assert the safety of it's extension modules, and demands 
that every module is signed by the Modula-3 compiler, or asserted by external 
means. References are called "capabilities" and are actually simple pointers, 
which are asserted by the compiler to be safe, and therefore do not need futher 
protection. This increases efficiency. In addition, because of the language 
feature of Modula-3 to define specific interfaces between modules, SPIN 
implements a "naming" protection which is based on namespace-domains with 
specific interfaces to the outer world. The names that are used in every 
modules interface are checked (and type-checked) against everything that the 
module is linked with. Finally, every procedure defined in a module's interface 
is considered to be an "event handler", whereas every imported procedure is an 
"event", meaning that as long as it typechecks, there can be any combination of 
event-handlers and events, and it can change at run time.
Based on that design, the main systems of SPIN are presented, namely memmory 
management, thread management and trusted access to physical resources.
In the last section of the paper, system performance is measured against two 
other operating systems, OSF/1 and Mach. SPIN is found to be a more efficient 
operating systems in the applications considered because it allows for better 
OS extensibility.
Overall, this is a well-written paper, that tries to present the big picture 
behind SPIN. Naturally, the presentation of a whole operating system cannot be 
completely covered in a paper, therefore, many details are missing. Moreover, 
the performance measurements section only uses two other operating systems, one 
of which shares a very large code base with SPIN, making it sound like only an 
improvement over OSF/1, even though the reader is promised in the introduction 
that the comparison includes "several other" operating systems.

Review from Nathaniel Waisbrot <waisbrot@cs> at Thu Feb 20 10:10:23 EST 2003:

	This paper provides an overview of the SPIN operating system, focusing on its 
extensible architecture, and its speed.  The central idea of SPIN is that all 
function calls are events, and all functions are event handlers.  The whole 
system is designed for dynamic linking from the ground up, so it's able to 
outperform older systems.
	SPIN's extensibility is discussed in more detail in the second paper, but I 
like the idea that everything is extensible.  Most programs wouldn't bother to 
manage their own VM or threads, but the statistics in the paper say that 
there's no cost incurred by the potential for extensions.
	Compared to recent papers we've read, SPIN's trusted computing base is  large 
(the system core and the Mod-3 compiler).  I assume that SPIN could be extended 
to use modules with proofs (so that the compiler wouldn't need to be trusted), 
but it seems like an acceptable risk to trust the core of the system.
	The statistics themselves were uninteresting.  It's impressive how well SPIN 
outperforms OSF/1 and Mach, but it was designed with modern hardware and 
programming methods in mind, so it would be pretty disappointing if it was 

Review from piyush bhagat <> at Thu Feb 20 11:36:48 EST 2003:

The paper is mainly about the Spin operating system and its architecture. It 
says that Spin provides an extension infrastructure, which enables the 
applications to specialize the operating system in order to achieve maximum 
performance or a particular level of performance. The paper claims the Spin 
operating system to be an extensible system and that it can dynamically 
specialized to meet the requirements of the applications. The paper underlines 
the four techniques that make Spin an extensible safe and a high performance 
operating system. The techniques are Co-location, Enforced Modularity, Logical 
protection domain and Dynamic call binding. The paper makes a very good point 
that these four techniques help in achieving extensibility but are not the only 
techniques that provide extensibility. Extensibility is finally obtained 
through system service interface.
In the rest of the paper the authors have discussed several topics like need 
for extensible systems, the architecture of Spin, the services provided by Spin 
and finally the performance and evaluation of Spin. These topics have been 
dealt with in a very general way and I think that they can be applied to other 
extensible systems also. The paper does not describe the architecture of Spin 
in detail which I think it should have.        

Review from James ROse <rosejr@cs> at Thu Feb 20 12:18:40 EST 2003:

	This paper describes the design of an operating system using
two important programming technologies: safe languages and event-based
programming.  For the most part, it seems straightforward to develop
an operating system in a type-safe language, and the benefits obtained
are the same ones obtained in application programming.  The
event-based model has also been done for a while now (though this
paper is rather old), but this paper offers an interesting
optimization of it.  Also, the way that they treat every procedure
call as an event seems like it could be very powerful.  What I find
interesting about this paper is that it seems to provides a good
solution to a problem that I have encountered: how to send
high-bandwidth video data to the appropriate places in the computer
while copying it as little as possible.  Although I found that this
problem was reasonably well handled by the design of UNIX, the
approach given in this paper is more generally applicable.

Review from Mujtaba Ali <> at Thu Feb 20 12:23:19 EST 2003:

The paper does a good job of hammering a couple of key points.  The use of 
language features (in this case, Modula-3) to provide extensibility, safety, 
and performance is a key differentiator between SPIN and other related efforts. 
 Using a language like Modula-3 allows SPIN to use direct procedure calls, 
boosting performance over related efforts.  Also, only extensions have to be 
coded in Modula-3; regular applications can be coded in any language.  
Furthermore, the authors are not afraid to disclose that a certain level of 
"safety by assertion" is required in any system and some operations, such as 
Resolve, must violate semantics.  Additionally, the SPIN extension model allows 
a programmer to avoid expensive operations that on conventional systems would 
repeatedly cross user/kernel boundaries.  Last, SPIN's extensibility model 
draws its flexibility from an event-based design.

A couple points are unclear, though.  The authors compare SPIN to conventional 
operating systems.  However, I believe these comparisons are invalid as SPIN is 
more of a meta-OS than a "real" operating system.  Also, at times, such as when 
memory management and thread management are discussed, it is clear that the 
memory management and/or thread management scheme can differ between 
concurrently running applications.  However, if a disk buffering/paging 
algorithm is changed, I don't see how such an algorithm could be applied only 
to one of many running applications.  This leads me to believe that SPIN is 
well-suited only for special, single-purpose systems.  Additionally, during the 
section on "Extensible thread management", the authors describe Mach's 
user-level C-Threads as anomalous; however, a couple paragraphs later, the SPIN 
thread framework is described and I believe the SPIN thread framework has a 
great probability for exhibiting anomalous behavior.

Review from Jeff Odom <> at Tue Feb 25 03:09:05 EST 2003:

The SPIN operating system allows for run-time modification of an OS in a 
type-safe matter.  The major motivator for such a design is that with the 
varying demands of different classes of applications, a general-purpose OS may 
not be optimized for all (or even any) of the classes - disk management 
requirements for a database may be completely orthogonal to a video server, for 
instance.  Instead of writing separate operating systems for each target 
environment, separate extensions to the same OS may be applied for each set of 
performance requirements.

Two features distinguish the SPIN OS.  First, modularity is incorporated at the 
language level.  Unlike shared-object kernel modules written in C, which 
popular OS flavors such as Solaris and Linux currently employ, SPIN requires 
type-soundness.  This has two advantages: correctness and safety.  Correctness 
of implementation is provided by requiring an extension to match a signature, 
thereby at least guaranteeing that the extension will be called correctly.  
Security is given by type-soundness - a pointer can only access objects of a 
compatible type, and not arbitrary memory.

The second distinguishing feature of SPIN is its kernel-extension interface.  
Unlike conventional operating systems, which utilize RPC or traps, each 
extension "event" is either a single direct procedure call or a sequence of 
several indirect calls.  This allows for decreased overhead relative to a 
conventional OS, as well as being able to eliminate a lot of unnecessary 
kernel-user translations.

Generated: Thu Mar 6 15:39:24 EST 2003 by mwh

Web Accessibility