Extensibility, Safety, and Performance in the SPIN Operating System

Bershad, Savage, Pardyak, Sirer, Fiuczynski, Becker, Chambers, and Eggers

One-line summary: This paper presents SPIN, an extensible operating system
that can be dynamically specialized to meet the needs of individual
applications.

Overview/Main Points

   * General Description:

        o The interfaces and/or implementation of general operating systems
          are seldomly optimal for applications. SPIN is general in that it
          provides extensibility, safety, and good performance, but also
          customizable in that it provides low-cost, fine-grained, protected
          access to OS resources, through:

            1. Co-location : Extensions are dynamically linked into the
               kernel space.
            2. Enforced modularity: Modula-3 magic... (interface boundaries,
               modules) Provides cheap isolation at compile time.
            3. Logical protection domains: Extensions are protected from
               each other but dynamically linked in a way that allows
               low-cost cross-domain communication.
            4. Dynamic call binding: Extensions are accessed through events
               and handlers associated (at run-time) with system events (low
               overhead).

        o Language features ensure safety within the kernel. However,
          applications can be written in any language and executed within
          their own virtual address space. (If one wants these in the
          kernel, they must be "trusted").

   * Architecture:

        o Modula 3 provides : static type-checking/type safety, dynamic
          linking, support for interfaces, automatic storage management,
          objects, generic interfaces, threads, and exceptions. Naming and
          the protection interface are in the language (not in virtual
          memory system).

        o Capabilities are unforgeable references to resources (i.e. system
          objects, interfaces, collections of interfaces). These are
          implemented using pointers, with the compiler ensuring that they
          cannot be forged, dereferenced improperly, or accessed by the
          unprivileged masses.

        o Extensions are defined in terms of events and handlers, which are
          registered through a central dispatcher. The right to call a
          procedure = the right to raise the event named by the procedure
          (must have access to the interface/domain).

        o The module that exports the procedure is the default
          implementation. Other modules may attempt to install additional
          handlers or remove the primary implementation. Handlers can be
          constrained in their execution (levels of trust).

        o Guards can be associated with handlers to restrict access at a
          finer granularity than events. (IP/protocol types example).

   * Core Services

        o Used to manage memory and processor resources.
             + Extensible memory management: fast, fine-grained control over
               physical and virtual memory resources.

             + Extensible thread management: Applications are able to
               provide their own thread packages and schedulers within the
               kernel. (The kernel defines the structure upon with the
               implementation of threads runs, but does not define the
               thread model for applications). Scheduling and
               synchronization within the kernel is handled completely by
               the kernel, using Modula-3 threads.

             + Global scheduler is replaceable by trusted admins (currently
               round-robin, preemptive, priority policy).

   * Performance
        o In comparison to Mach and OSF/1, protected communication is much
          cheaper (from 20% to 800%, respectively). The thread
          implementation and virtual memory management also perform
          favorably.

        o Reasonable and realistic application examples are presented (some
          with performance statistics), including TCP/IP (with redirection),
          a network video system, and an http server.

Conclusions

Spin seems to offer good performance, extendibility, and fine grain access
to resources while maintaining safety. This flexibility is impressive, and
clearly a win for applications with specific needs not addressed
sufficiently by general operating systems.

These features come with a price, however - the system depends very heavily
upon Modula 3, which may impose limitations upon application writers and
present hidden dangers.

Questions

How exactly is access to objects controlled? Are there access lists that the
compiler uses to restrict application rights?

How does the system perform in benchmarks when multiple users are running?
  ------------------------------------------------------------------------
Back to index