Early operating systems were control programs a few thousand bytes long that scheduled jobs, drove peripheral devices, and kept track of system usage for billing purposes. Modern operating systems are much larger, ranging from hundreds of thousands of bytes for personal computers (e.g. MS-DOS, Xenix) to tens of millions of bytes for mainframes (e.g. Honeywell's Multics, IBM's MVS, AT&T's Unix) and hundreds of millions of bytes for some servers (Microsoft's Windows NT). In addition to managing processors, memory, and dozens of input-output devices, modern operating systems also provide numerous services such as Internet communications, Web communications, interprocess communications, file and directory systems, data transfer over local networks, and command languages and graphical user interfaces for invoking and controlling programs. These high-level services hide the primitive facilities of the base computer, such as interrupts, status registers, and device interfaces, from the user. The operating system builds its high- level services by wrapping the low-level hardware facilities in layers of software, resulting in a powerful virtual machine that is much easier to use than the basic hardware. Thus an operating system provides two classes of functions: orderly allocation of computing resources among processes contending for them, and an extended machine that provides a powerful programming environment. These two classes are not independent; poor structure can make resource allocation a nightmare. The microkernel architecture to be discussed below is a good structure that enables efficient resource allocation and powerful programming environments.

Microkernels are minimal but highly flexible kernels. Both c on- ventional and non-classical operating systems can be built on top or adapted to run on top of them. Microkernel-based architectures should particularly support extensibility and customizab ility, ro- bustness including reliability and fault tolerance, prote ction and security. After desastrous results in the early 90's, the microkernel ap- proach now seems to be promising, although it still bears a lot of research risks. Currently, University of Karlsruhe's sy stem ar- chitecture group is defining the state of the art in microkern el re- search. The L4Ka research project aims at substantiating and establish- ing a new methodology for system construction that helps to man- age ever-increasing OS complexity and minimizes legacy depen- dence. Our vision is a microkernel technology that can be and is used advantageously for constructing any general or customized operating system including pervasive systems, deep-computing systems, and huge servers. The technology should help to manage ever-increasing OS complexity, enable stepwise innovations in OS technology while preserving legacy compatibility, and lead to a widely-accepted foundation of system architecture.

Orthogonal persistence opens up the possibility for a number of applications. We present an approach for easily enabling transparent orthogonal persistence, basically on top of a modern μ-kernel. Not only are all data objects made persistent. Threads and tasks are also treated as normal data objects, making the threads and tasks persistent between system restarts. As such, the system is fault surviving. Persistence is achieved by the means of a transparent checkpoint server running in user-level. The checkpoint server takes regular snapshots of all user-level memory in the system, and also of the thread control blocks inside the kernel. The execution of the checkpointing itself is completely transparent to the μ-kernel, and only a few recovery mechanisms need to be implemented inside the kernel in order to support checkpointing. During system recovery (after a crash or a controlled shutdown), the consistency of threads is assured by the fact that all their user-level state (user memory) and kernel-level state (thread control blocks) will reside in stable storage. All other kernel state in the system can be reconstructed either upon initial recovery, or by standard page fault mechanisms during runtime.

We present a framework that allows applications to build and customize VM services on the LA microkernel. While the LA microkernel's abstractions are quite powerful, using these abstractions effectively requires higher-level paradigms. We propose the dataspace paradigm which provides a modular VM framework. The modularity introduced by the dataspace paradigm facilitates implementation and permits dynamic configurability. Initial performance results from a prototype are promising

Lazy switching enables very fast blocking intra-task IPC between kernel-implemented threads. This type of IPC can typically be entirely executed in user mode, although it operates on kernel objects. We hope that lazy switching adds the advantages of user level threads to kernel-level threads. The work on lazy switching is ongoing research in its early stage. Whether all its promising properties can make it to reality is still open.

As IPC mechanisms become faster, stub-code efficiency becomes a performance issue for local client/server RPCs and inter-component communication. Inefficient and unnecessary complex marshalling code can almost double communication costs. We have developed an experimental new IDL compiler that produces near-optimal stub code for gcc and the L4 microkernel. The current experimental IDL4 compiler cooperates with the gcc compiler and its x86 code generator. Other compilers or target machines would require different optimizations. In most cases, the generated stub code is approximately 3 times faster (and shorter) than the code generated by a commonly used portable IDL compiler. Benchmarks have shown that efficient stubs can increase application performance by more than 10 percent. The results are applied within IBM's SawMill project that aims at technology for constructing multi-server operating systems.

Interprocess (IPC) monitoring enables the examination of any IPC between a source and a destination. IPC monitoring is useful for a variety of purposes, including debugging, logging, and security. For example, a monitor may collect communication state for the purpose of debugging a program consisting of several independent tasks. Also, a monitor can be used to filter communication data or control the communication rate for security purposes.Transparent monitoring means that the source and destination are not aware that they are being monitored. This has two advantages: (1) the system can control the insertion and removal of monitors without interacting with either the source or destination and (2) the source and destination protocols do not need to take into account the possibility that they may be monitored. Traditional systems make no attempt to support transparent monitoring. Using Mach-style ports [1], the source and destination hold rights that must be revoked in order to insert a monitor, so at least one must be notified before such a change can occur safely. The Pebble microkernel enables transparent redirection of source IPCs using its portals to implement customized IPC, but the redirection is not transparent to the destination because it sees that the message is from the redirected task, not the original source [3].Other IPC mechanisms, such as Clans & Chiefs [6] and IPC Redirection [2], enable monitors to intercept and forward IPCs while claiming to be the original source of the IPC. Thus, the destination receives the IPC from the source, not the monitor, so it need not know that an IPC is being monitored. Unfortunately, such mechanisms are not truly transparent because the kernel's IPC semantics are not preserved when a monitor intercepts an IPC. Modern microkernels implement a synchronous IPC semantics, which means that the source is blocked until the destination is ready to receive the IPC or an error occurs (e.g., the destination task is killed or a timeout expires). When destination commences receipt, the IPC is sent to the destination and the source unblocks. Unfortunately, if a monitor is inserted on an IPC path, the source is unblocked when the IPC is received by the monitor, not the destination. This may result in some anomalous behaviors, such as: (1) the source assuming that IPCs have been delivered to the destination before they really have; (2) the source terminating IPCs due to timeout expiration even though the destination is ready, but because the monitor was not ready; and (3) the source assuming that the IPC was delivered reliably to the destination when an error may have occurred.In this paper, we propose an IPC mechanism that restores synchronous IPC semantics over transparent monitors. The key feature of this mechanism is that system monitors are considered as an extension of the kernel, so the source and destination are treated as if the kernel is still processing the IPC. However, there are a number of possible monitoring extensions that must be considered, and these introduce a number of problems that must be solved simultaneously. Our design enables layering of these additional semantics upon system monitors as necessary.The remainder of the paper is as follows. In Section 2, we define the basic synchronous IPC semantics that must be achieved and refine these semantics for relevant extensions. In Section 3, we construct a synchronous IPC protocol that solves these problems by incrementally extending a basic IPC mechanism. In Section 4, we demonstrate the use of the synchronous IPC mechanism on an example which both redirects and controls the rate of IPCs securely. In Section 5, we examine efficient implementations of the synchronous IPC mechanism upon the L4 microkernel using the IPC redirection mechanism. In Section 6, we conclude the paper.

Multiserver systems, operating systems composed from a set of hardware-protected servers, initially generated significant interest in the early 1990's. If a monolithic operating system could be decomposed into a set of servers with well-defined interfaces and well-understood protection mechanisms, then the robustness and configurability of operating systems could be improved significantly. However, initial multiserver systems [4, 14] were hampered by poor performance and software engineering complexity. The Mach microkernel [10] base suffered from a number of performance problems (e.g., IPC), and a number of difficult problems must be solved to enable the construction of a system from orthogonal servers (e.g., unified buffer management, coherent security, flexible server interface design, etc.).In the meantime, a number of important research results have been generated that lead us to believe that a re-evaluation of multiserver system architectures is warranted. First, microkernel technology has vastly improved since Mach. L4 [13] and Exokernel [6] are two recent microkernels upon which efficient servers have been constructed (i.e., L4Linux for L4 [12] and ExOS for Exokernel [9]). In these systems, the servers are independent OSes, but we are encouraged that the kernel and server overheads, in particular context switches overheads, are minimized. Second, we have seen marked improvements in memory management approaches that enable zero-copy protocols (e.g., fbufs [5] and emulated copy [3]). Other advances include, improved kernel modularity [7], component model services [8], multiserver security protocols, etc. Note that we are not the only researchers who believe it is time to re-examine multiservers, as a multiserver system is also being constructed on the Pebble kernel [11].In addition, there is a greater need for multiserver architectures now. Consider the emergence of a variety of specialized, embedded systems. Traditionally, each embedded system includes a specialized operating system. Given the expected proliferation of such systems, the number of operating systems that must be built will increase significantly. Tools for configuring operating systems from existing servers will become increasingly more valuable, and adequate protection among servers will be necessary to guard valuable information that may be stored on such systems (e.g., private keys). This is exactly the motivation for multiserver systems.In this paper, we define the SawMill multiserver approach. This approach consists of: (1) an architecture upon which efficient and robust multiserver systems can be constructed and (2) a set of protocol design guidelines for solving key multiserver problems. First, the SawMill architecture consists of a set of user-level servers executing on the L4 microkernel and a set of services that enable these servers to obtain and manage resources locally. Second, the SawMill protocol design guidelines enable system designers to minimize the communication overheads introduced by protection boundaries between servers. We demonstrate the SawMill approach for two server systems derived from the Linux code base: (1) an Ext2 file system and (2) an IP network system.The remainder of the paper is structured as follows. In Section 2, we define the problems that must be solved in converting a monolithic operating system into a multiserver operating system. In Sections 3 and 4, we define the SawMill architecture and the protocol design approach, respectively. In Section 5, we demonstrate some of these guidelines in the file system and network system implementations. In Section 6, we examine the performance of the current SawMill Linux system.

Main memory is typically significantly slower than the processors that use it. Such slow memory is then amortized by fast caches. Effective scheduling, particularly for soft or hard real-time, has therefore to include cache control, even on uniprocessors. Although cache scheduling is currently still an open research issue, we assume in this paper that uniprocessors are effectively schedulable in the presence of caches.In this paper, we focus on SMP-specific memory scheduling. A small SMP multiprocessor typically incorporates multiple processors (with per-processor caches) that work on a global main memory. Processors and main memory are connected by a single memory bus, i.e. all processors share the same bus.Assume that we have 4 job mixes that can be correctly scheduled on 4 independent uniprocessors. What happens if we put those 4 job mixes on a 4-processor system with a single memory bus? Without any additional scheduling provisions, the shared memory bus can, in the worst case, stretch each schedule by a factor of 4. This is clearly unacceptable. In general, it would mean that the real-time capacity of an n-processor system is only 1/n of the capacity of a uniprocessor system. Multiprocessors would be unusable for real-time applications.Therefore, memory-bus scheduling is desirable. Memory-bus scheduling should enable us to give soft and perhaps even hard guarantees in relation to memory bandwidth and latency to real-time applications. For non real-time applications, it should help optimize a system's overall throughput and/or latency.

Most modern wide-address computer architecture do not prescribe a page table format, but instead feature a software-loaded TLB, which gives the operating system complete flexibility in the implementation of page tables. Such flexibility is necessary, as to date no single page table format has been established to perform best under all loads. With the recent trend to kernelised operating systems, which rely heavily on mapping operations for fast data movement across address-spaces, demands on page tables become more varied, and hence less easy to satisfy with a single structure. This paper examines the issue of page tables suitable for 64-bit systems, particularly systems based on microkernels. We have implemented a number of candidate page table structures in a fast microkernel and have instrumented the kernel’s TLB miss handlers. We have then measured the kernel’s performance under a variety of benchmarks, simulating loads imposed by traditional compact address spaces (typical for UNIX systems) as well as the sparse address spaces (typical for microkernel-based systems). The results show that guarded page tables, together with a software TLB cache, do not perform significantly worse than any of the other structures, and clearly outperform the other structures where the address space is used very sparsely.

We present a security architecture that enables system and application a ccess control requirements to be enforced on applications composed from downloaded executable content. Downloaded executable content consists of messages downloaded from remote hosts that contain executables that run, upon receipt, on the downloading principal's machine. Unless restricted, this content can perform malicious actions, including accessing its downloading principal's private data and sending messages on this principal's behalf. Current security architectures for controlling downloaded executable content (e.g., JDK 1.2) enable specification of access control requirements for content based on its provider and identity. Since these access control requirements must cover every legal use of the class, they may include rights that are not necessary for a particular application of content. Therefore, using these systems, an application composed from downloaded executable content cannot enforce its access control requirements without the addition of application-specific security mechanisms. In this paper, we define an access control model with the following properties: (1) system administrators can define system access control requirements on applications and (2) application developers can use the same model to enforce application access control requirements without the need for ad hoc security mechanisms. This access control model uses features of role-based access control models to enable (1) specification of a single role that applies to multiple application instances; (2) selection of a content's access rights based on the content's application and role in the application; (3) consistency maintained between application state and content access rights; and (4) control of role administration. We detail a system architecture that uses this access control model to implement secure collaborative applications. Lastly, we describe an implementation of this architecture, called the Lava security architecture.