CS 736 - Spring 2007 - Paper Discussion

Summary:

The paper describes SPIN, an extensible OS which allows applications to safely change the operating system's interface and implementation. The extensible architecture is based on language and link-time mechanisms for fine-grained, inexpensive and safe access to system services.

Problem:

Applications' resource requirements may be poorly matched by a general purpose Operating System. This may lead to a poor performance or compromised functionality on the part of the application. The idea here is tunability where fine-grained control over resources of the OS leads to better management of the resources based on application requirements. Also, the extensions offered have to be low cost and safe.

Contributions:

The approach of using a monolithic kernel which provides low-cost and very fine-grained control over system services with lesser programming effort, which is aptly contrasted to other approaches which are microkernel based, direct extension "hacks" into weakly protected monolithic kernels (such as MS-DOS, Windows, *nixes), protected procedure call methods or user-land exported functions as libraries.
The idea of using compiler enforced modularity for security which neatly divides kernel code from extensions at an OS level. Co-location enables communication between extension and system code at low cost. The inexpensive implementation of multiple handlers to a single event seems to be a new contribution of the time. Automatic storage management is shown to have minimal performance penalty.

Flaws:

The application programmer handling events have to take additional care while writing handlers as they may be run synchronously. From the lack of discussion, it seems that the OS is not intended to run many applications in a time-sharing manner, although it seems possible, by a complicated guard function which on every process switch reschedules different event handlers. The application has the potential for malicious behavior with such fine-grained access in a time-shared system. (for example, a real-time application changing the scheduling policy is not malicious). Since the OS is pretty much usable for a single application at one time, the "hack" based extensions into weakly protected kernels (C-based linux etc) may not be altogether a bad idea. The programming complexity is debatable.

Relevance:

The overall idea of the system is very desirable, although the OS appears to be single-user/application at a given time.

Summary:
The SPIN idea is similar to HYDRA. Both systems are highly extensible, but SPIN is an attempt to demonstrate that a system can offer extensibility, safety, and performance. Much of this was made possible by "co-locating" kernel extensions and the kernel to allow efficient communication. Modula-3's language features also enforce modularity to an extent, making extensible/modular code easier to produce.

Problem:
SPIN is an attempt to address performance issues created by different classes of resource use. By allowing users to switch out different parts of the operating systems, the SPIN authors also create two additional problems: how to allow this extensibility, and how to allow it safely.

Contributions:

• Garbage collection and performance are not mutually exclusive
• Capabilities and performance are also not mutually exclusive
• Related to the above two: Modula-3 and SPIN are a great match. Modula-3's language features essentially guarantee that SPIN doesn't have to work very hard to provide safety and extensibility.
• Protection domains are enforced by Modula-3, instead of at the virtual memory level.

Flaws:

• I'd like to see a more thorough examination of the security model. It seems like voodoo to say that "Modula-3 takes care of everything so don't panic!" Using capabilities offers some level of comfort, but I remain unconvinced.
• The code snippets should've been in pseudo-code.
• If SPIN allows device drivers from different operating systems to be used, I find it hard to believe that the system is as safe as claimed.

Relevance:
As others have mentioned, most operating systems offer some level of extensibility/modularity. The core contribution of SPIN is that by guaranteeing certain properties, such as pointer authenticity and type safety, you can begin to make certain claims as to the "safety" of the operating system.

Summary:
The paper presents the architecture of SPIN OS, which is a dynamically extensible operating system. The paper also provides some performance comparisons with other OS.

Problem:
Most operating systems strike a balance beteween generality and specialization. Though most general-purpose systems can be custommized, it is at the cost of performance and/or safety. SPIN attempted to create a system with high level of extensibility while not compromizing on performance or safety.

Contributions:
- The biggest contribution of the paper is the use of language (modula-3) features to create safe extensions to the kernel. Since the compiler performs all the type and interface compatibility checking, the runtime environment does not have to worry about those operations. This improves performance.
- The extension model presented in this paper is also interesting. It allows extensions to install handlers on any system event, and multiple extensions can install condition-based handlers for the same event, allowing high level of customization.
- Compared to many other systems we have seen so far, SPIN includes a core set of services (like those that manage memory and processor resources) in the system.
- Another contribution of the system is dynamic mapping of service interfaces with the use of an in-kernel nameserver, allowing multiple implementations of a given interface to exist and be dynamically changed at run time.

Flaws:
- There is no question the system is highly extensible through multiple event handlers, but there seems to be no limit on the number or semantics of event handlers. This could mean that a given event handling may take forever to complete, thus bringing down the service.
- Completely relying on compiler for protection sounds like a bad idea, because I think forging a sign wouldnt bee too difficult for any hacker. Could have struck a balance between runtime and compiletime checks.
- Couldnt make out if some performance tests were done on heavily loaded(i.e extended) system. It would be interesting to see how the system (or a core service - like VM) performs when there are multiple extensions (some of which may not be highly optimized)

Relevance:
The paper shows the 'correct' way of going about a research - defining problem, studying existing similar work, explaining the solutions, justifying the claims through tests. The system itself is highly extensible and some of these techniques are used in modern operating system as well. However I am not sure if we need this level of customization on many systems.

Summary
This paper discusses the SPIN operating system, "an operating system that can be dynamically specialized to safely meet the performance and functional requirements of applications."

Problem
The problem that is being addressed in this paper is the insufficiency of other operating systems to meet the demands of sepcific applications, that is to say that the operating systems make interface and implementation decisions that may not be suited to particular applications. This paper attempts to address that problem by allowing applications to use the hardware facilities in the manner that they need.

Contributions
The main contribution of this paper is a system that safely provides "fine-grained access to system services" This is achieved by providing a programming language that is used to safely extend system interfaces because it provides type safety and security restrictions are enforced at compile-time. Several services are provided to these kernel extensions.

Flaws
Overall this seems to be a a reliable method for allowing extension of system interfaces. The only problem that I can see with this is that the idea of signed object files being created by a Modula-3 compiler. If you allow untrusted sources to run signed object files in kernel space, and you allow a signing compiler to be publicly availabe, someone will inevitably reverse engineer the signing routine, even if the signing compiler is only available as a remote server, if a bug is found and exploited in the compiler the signed versions of the exploit code will remain in the wild even after the compiler has been fixed.

Relevance
This system is somewhat similar to extension systems currently in use today such as kernel modules in linux, but it is able to provide a greater degree of flexibility and safety. Today, the ability to change the interface/implementation of system services for specific applications is sometimes used in special purpose programs, but is not commonly used, and their is no guarantee of safety and the program doing so must have root privilege. One notable example of this is the Sony rootkit or XCP software which patched the Windows kernel to prevent certain files, registry entries and processes from being discovered by users or antivirus tools.

Summary:
This paper describes an operating system “SPIN” which provides a mechanism for the application programmer to customize the interface by adding an extension to the core system with out giving up or even taking an advantage about the performance and safety that is caused by the extensibility of the system.

Problem:
The challenging of SPIN was to create a flexible and customizable system without a lot of overhead, and also safety so that extensions and applications that use them won’t hurt the whole system. Previous systems had some approach for giving applications a big power so that they can optimize the operating system but those had a problem with performance or the cost of implementing it.

Contributions:
By fully utilizing the merit of Modula-3 language such as automatic storage management and using an original extension model, SPIN enabled to develop various types of applications that can fully utilize the OS with appropriate cost.

Not only rejecting the existing mechanisms and codes, SPIN enabled to create previous mechanism and also to utilize the codes written in other language such as C.
The way they define safe code was interesting. Basically, of course the codes are safe if kernel knows the file. But also kernel had some other way to make sure that the code is safe and guaranteed. Also, even if one of the extensions crashes, the whole system will not collapse by stopping at the border of interface.

Finding the balance point and architecture that enabled placing the extension close to the system core, still have a safety mechanism, and acceptable overall performance should be really difficult and it is valuable.

Also, the way clarify the mechanism and characteristic not only by explaining the outline but including code snippets and evaluation by comparing with other systems were straight forward and understandable.

Flaws:
As many people are pointing out, the way that SPIN assert the safety which is one of the main aspects, seems to be a little loose. I think if SPIN depends a lot on Modula-3 and thinks that language is easy enough to learn too, they should have restricted to use that language. But same as the security in the internet, it is true that is really difficult to create an open architecture with safety.
Also it might be clear but because SPIN is highly depending on Modula-3 language, there must be a limit of optimizing the performance of SPIN, but I guess this is not a problem that actually matches to some of the goal.

Relevance:
I think extensibility and safety is still discussable in current systems too. Also not only in operating systems such as plug-ins of applications, it is really difficult to find a reasonable answer for the balance of rights to control, separating the modules, and keeping safe. The level of abstraction and the size and coverage of the core system is really different but I felt that SPIN is some how a bit similar to building an OS on Java with more customizability and access to deeper inside the systems. Then again I will concern about the correctness or reliability of that base language.

Summary
SPIN is a system that allows dynamic linking of modules into the kernel in order to allow applications to use custom mechanisms if desired.

Problem
Operating systems cannot be well tuned to every application. The authors desired to create a method to safely allow application to supply modules to fine tune the system to their needs.

Contributions

• Dynamically linked modules inside the kernel space for quick access.
• Event driven operating system. An event can have many handlers.
• Focus on code safety at compile time. By using a type safe language to ensure a higher level of correctness for code that will be executed in the kernel.
• Completed analysis of their system using a number of benchmarks.
• Good summary of related work.

Flaws
The authors did a wonderful job of justifying compile time safety checks, but I am not convinced that these will provide safety. The authors themselves added “safe by assertion” functionality to enable the user to load arbitrary code into the kernel. In the case of their prototype to load hardware drivers. The authors themselves found it too cumbersome to rewrite the drivers in Modula-3. If this is the case I feel it is unlikely that many others, who have less incentive to follow proper procedure, will rewrite their code in Modula-3. If a good minority of users is bypassing the system used to ensure safety, then any claims about the system’s safety are in question. It is also not clear how SPIN will be. Applications running arbitrary code in kernel would allow them to bypass any protection mechanisms.

Relevance
Introduced a novel idea at extending the basic kernel through adding modules inside the kernel address space. This seems somewhat similar to the *nix approach. Other than this the system has the feel of modern operating systems, but is very different in the details.

Summary

This paper presents an operating system that provides an extension infrastructure with the help of events and event handlers which allows applications to modify the operating system’s interface and implementation to optimize their performance.

Problem Description

General purpose operating systems have to support a vast variety of applications. As a result a lot of generality is added to different features implemented in an operating system which makes the operating system relatively inefficient. The authors suggest that most general systems can be specialized to address the performance requirements of a particular application but the existing systems are not well-suited for specialization and they often require substantial programming effort. To address these problems, the authors propose an operating system which is designed by keeping its extensibility in mind so that it can be changed dynamically to meet the needs of an application.

Summary of Contributions

Some of the contributions of this paper are as follows.
1. The major contribution of this paper is that it presents an operating system that designed by keeping the extensibility infrastructure in mind. Compared to other operating systems existing at that time, it was quite easy to optimize SPIN operating system for a specific application using the events and event handling scheme proposed in the paper. Software developers can write optimized event handlers to efficiently handle specific events. Instead of using the default event handler, SPIN will use the optimized event handler for that specific application.
2. The idea of safe and unsafe object files is also presented in this paper. An object file is considered safe if it is unknown to the kernel but has been signed by the compiler or if the kernel can assert the file to be safe. This idea seems somewhat similar to feature provided in modern Windows operating system which checks if the driver is digitally signed or not. This adds a level of security before the extension is actually applied to the kernel.
3. The paper also proposes the idea of isolating the extensions applied to the operating system. As a result, an extension’s failure to use an interface is isolated to the extension and any other applications that rely on that extension.
4. For efficient protected communication between extensions and core system, SPIN extension model offers simple procedure calls rather than system calls. Secondly, SPIN also allows applications to define specialized fault handling. As a result, user/kernel boundary crossings are avoided and required functionality is implemented precisely.

Flaws

Some of the flaws in the paper are as follows.
1. There seems to be a security hole in SPIN. It is quite easy to write malicious extensions for SPIN. People can install those extensions in their systems and as a consequence the application that generates the events being handled by the malicious extension can severely be effected.
2. Increasing the number of event handlers can significantly impair the performance of the dispatcher which can affect the performance of the applications running. The authors claim that the dispatcher latency increases linearly with the number of guards and number of event handlers. The number of events being handled by the dispatcher every second is another thing that can affect the performance of the dispatcher. As the number of events generated increases, more and more events will be queued and the applications generating those events will be affected a lot.
3. In the “System Performance” section, the authors present a lot of numbers showing that SPIN is much better that DEC OS and MAC OS but the authors do not justify these numbers. It is not discussed what was the reasons because of which SPIN performed better.
4. The authors have shown a lot of code snippets in the paper which I think have no relevance to the paper. Even if those snippets were not shown it would not have made any difference.

Relevance

I am not sure if the concept of extensible operating system is being used these days. All of the modern operating systems that I know of do not provide this functionality. Sometimes, certain patches are provided in case of UNIX/LINUX that can be added to the kernel in order to increase the performance of certain programs e.g. database related programs that access the disk a lot but it requires the kernel to be recompiled. Device drivers used these days are some what similar to the idea presented in the paper i.e. they can be installed later and can be used instead of the default drivers implemented in the OS but they are not used to improve the performance of a specific application.

Summary
This paper details the SPIN architecture and provides an initial analysis and comparison of the system to other previously developed operating systems. The SPIN architecture is shown to provide speed and functionality improvement over the other systems.

Problems addressed
The main objective addressed in this work is that of matching application demands to the operating system implementation. Its noted that different applications may demand different functionality from the operating system. Some applications may require a particular behaviour or function to run efficiently while other applications may require a different behaviour that may contradict the behaviour demanded by the first application. Traditionally to deal with this situation the operating system tries to provide for both while sacrificing performance of both applications. SPIN directly addresses this issue by allowing custom kernel extensions to be built that provide a specific behaviour for a particular application.

Contributions
A modular system is often the most flexible and can adapt to differing application work loads. It is thus the implementation of this idea into the heart of an operating system that seems to be a significant contribution. Protection remains a large concern for the SPIN system to prevent code from crashing the system or effecting other processes running in different protection domains. The authors realized this from the start and built in mechanisms for maintaining this protection while still allowing for fairly low level services to be invoked efficiently.

Flaw
It seems as though that if there were too many extensions that implement a particular event the dispatcher logic that routes events to appropriate handlers could consume a fairly large amount of time decreasing system performance. Also it was unclear to me how resources were allocated to newly created protection domains other then a reference to a "safe object file" that was not explained very well.

Relevance
To this day operating system developers debate what should be built into the kernel, what can be added later by way of a module or extension or left up to the application. The idea of modules in Linux appears to be similar to this approach except that in the case of Linux I don't believe the modules can be as easily swapped in and out by the application. However these modules still provide a means of adding new functionality to Linux without requiring the kernel be rebuilt.

Paper Review: Extensibility, Safety, and Performance in the SPIN Operating System [Bersad, et. al.]

Summary:

This paper presents SPIN, an extensible operating system focusing
on retaining safety and performance with respect to its exentsions.

Problem:

The problem addressed by SPIN was to implement an operating system that
was tunable, through extensions, to the needs of demanding applications,
but without allowing unsafe application code to execute in the kernel
and without the degraded performance of prior extensible
capability-based systems.

Contributions:

SPIN selected a novel high-performance method to implement fine-grained
isolation of extensions. It requires the use of Modula-3, a language
with interfaces, type safety, and automatic storage management, for the
extensions. This has safety, expressibility, and performance advantages
over some alternatives. The alternatives are using unsafe C (essetially
trusted as kernel code), using a restricted "little language", or doing
extensive run-time type or capability checking, respectively.

Flaws:

SPIN uses an event driven model to invoke extensions: the core operating
system dispatches control into handlers when related events occur. It
allows the the arbitrary attachment of "guard" rules to be run before
control is dispatched. Because of this and since extensions can be
hierarchical or stacked, it seems that the backlog for the dispatcher is
not bounded, which could make it a performance bottleneck with some set
of extensions.

It is not clear how default implementation modules can intelligently
decide whether or not other modules (extensions) can be added. How does
it know they won't negatively impact the desired overall system
behavior? If the decision is just that of the system adminstrator, who
can load "signed" Modula-3 extensions or any other "trusted" extension,
then how will it be improvement over the supposed "chaos" of today with
Unix and Windows device drivers?

It is not clear to me, from the paper, how extensions written in other
languages can be safely integrated into this system without existing in
a wholly seperate domain (protected virual address space) and thus
incurring more performance overhead than just the procedure call into a
purely Modula-3 extension.

Relevance:

I wonder whether the level of tunability that SPIN permits is necessary
in time-sharing systems, i.e. those with application that must be
protected from each other. It seems more targeted to applications that
would already have a dedicated machine, and therefore could be
implemented as normal (technically "unsafe") application-specific device
drivers. The sort of application-specific extensions that SPIN permits
could be implemented on either a dedicated tunable Unix with real-time
extensions OS (such as HP-UX) or on one of many commercial real-time
kernels, which are designed to be integrated with application
extensions. These solutions likewise involve the inconvenience of
platform-specific code to gain the extension/customized behavior and

Summary:
The authors describe SPIN, an operating system designed so that it's easy/possible to write rich extensions that live in kernel space but are still safe, so don't have to be fully trusted.

Problem:
Previous OSs that provided the degree of flexibility the authors wanted did so at the expense of either performance (by dropping into user space) or memory safety.

Contributions:
* A demonstration that writing an OS in a type-safe language didn't kill performance and was a reasonable approach, despite a widespread perception that C is "the" language for systems programming
* Same as above, but with garbage collection
* Demonstration that having an OS that could support custom extensions could improve performance in many areas by allowing the extension to manage resources in a particularly effective manner

Flaw:
This seems like a pretty solid paper to me. The one thing that I will say is that while their setup protects against many sorts of bugs, it doesn't appear to do much against maliciousness. If it's possible to forge the signature of the Modula-3 compiler (which seems like it would be nearly impossible to stop), then unsafe extensions could be made to look safe. This in turn implies that the privilege to load extensions still has to be rather restrictive. (The authors almost seem to want proof-carrying code, which would both protect against maliciousness and also allow extensions to be written in any language without having to resort to the "I trust this" method they used to load the network driver written in C.) However, this is not so much a flaw per se, because they still get protection against bugs without making the security situation any worse, and protection against maliciousness or allowing normal users to load these extensions wasn't a stated design goal of the system.

Relevance:
Almost all OSs used today still have drivers and extensions written in languages such as C or C++ running in kernel space, which provides ample avenues for them to crash the system. For instance, I've read that a majority of the crash reports filed to Microsoft are due to third party drivers. Enforced type safety might help improve reliability in this area. (It wouldn't solve the problems though.)