Complete formal verification is the only known way to guarantee that a system is free of programming errorsWe present our experience in performing the formal, machine-checked verification of the seL4 microkernel from an abstract specification down to its C implementation We assume correctness of compiler, assembly code, and hardware, and we used a unique design approach that fuses formal and operating systems techniques To our knowledge, this is the first formal proof of functional correctness of a complete, general-purpose operating-system kernel Functional correctness means here that the implementation always strictly follows our high-level abstract specification of kernel behaviour This encompasses traditional design and implementation safety properties such as the kernel will never crash, and it will never perform an unsafe operation It also proves much more: we can predict precisely how the kernel will behave in every possible situationseL4, a third-generation microkernel of L4 provenance, comprises 8,700 lines of C code and 600 lines of assembler Its performance is comparable to other high-performance L4 kernels

/pdf/sel4-formal-verification-of-an-os-kernel-20d8n4rs7p.pdf

seL4: formal verification of an OS kernel

Commodity computer systems contain more and more processor cores and exhibit increasingly diverse architectural tradeoffs, including memory hierarchies, interconnects, instruction sets and variants, and IO configurations. Previous high-performance computing systems have scaled in specific cases, but the dynamic nature of modern client and server workloads, coupled with the impossibility of statically optimizing an OS for all workloads and hardware variants pose serious challenges for operating system structures.We argue that the challenge of future multicore hardware is best met by embracing the networked nature of the machine, rethinking OS architecture using ideas from distributed systems. We investigate a new OS structure, the multikernel, that treats the machine as a network of independent cores, assumes no inter-core sharing at the lowest level, and moves traditional OS functionality to a distributed system of processes that communicate via message-passing.We have implemented a multikernel OS to show that the approach is promising, and we describe how traditional scalability problems for operating systems (such as memory management) can be effectively recast using messages and can exploit insights from distributed systems and networking. An evaluation of our prototype on multicore systems shows that, even on present-day machines, the performance of a multikernel is comparable with a conventional OS, and can scale better to support future hardware.

/pdf/the-multikernel-a-new-os-architecture-for-scalable-multicore-1zaxph0v39.pdf

The multikernel: a new OS architecture for scalable multicore systems

The present invention relates generally to systems and methods for measuring an analyte in a host. More particularly, the present invention relates to systems and methods for transcutaneous measurement of glucose in a host.

Transcutaneous analyte sensor

Communication is becoming one of the central elements in software development. As a potential typed foundation for structured communication-centred programming, session types have been studied over the last decade for a wide range of process calculi and programming languages, focussing on binary (two-party) sessions. This work extends the foregoing theories of binary session types to multiparty, asynchronous sessions, which often arise in practical communication-centred applications. Presented as a typed calculus for mobile processes, the theory introduces a new notion of types in which interactions involving multiple peers are directly abstracted as a global scenario. Global types retain a friendly type syntax of binary session types while capturing complex causal chains of multiparty asynchronous interactions. A global type plays the role of a shared agreement among communication peers, and is used as a basis of efficient type checking through its projection onto individual peers. The fundamental properties of the session type discipline such as communication safety, progress and session fidelity are established for generaln-party asynchronous interactions.

http://www.sti.uniurb.it/events/sfm15mp/slides/yoshida.pdf

Multiparty asynchronous session types

This paper describes the design, implementation and evaluation of Native Client, a sandbox for untrusted x86 native code. Native Client aims to give browser-based applications the computational performance of native applications without compromising safety. Native Client uses software fault isolation and a secure runtime to direct system interaction and side effects through interfaces managed by Native Client. Native Client provides operating system portability for binary code while supporting performance-oriented features generally absent from web application programming environments, such as thread support, instruction set extensions such as SSE, and use of compiler intrinsics and hand-coded assembler. We combine these properties in an open architecture that encourages community review and 3rd-party tools.

/pdf/native-client-a-sandbox-for-portable-untrusted-x86-native-3q4zair7xh.pdf

Native Client: A Sandbox for Portable, Untrusted x86 Native Code

Message-based communication offers the potential benefits of providing stronger specification and cleaner separation between components. Compared with shared-memory interactions, message passing has the potential disadvantages of more expensive data exchange (no direct sharing) and more complicated programming.In this paper we report on the language, verification, and run-time system features that make messages practical as the sole means of communication between processes in the Singularity operating system. We show that using advanced programming language and verification techniques, it is possible to provide and enforce strong system-wide invariants that enable efficient communication and low-overhead software-based process isolation. Furthermore, specifications on communication channels help in detecting programmer mistakes early---namely at compile-time---thereby reducing the difficulty of the message-based programming model.The paper describes our communication invariants, the language and verification features that support them, as well as implementation details of the infrastructure. A number of benchmarks show the competitiveness of this approach.

/pdf/language-support-for-fast-and-reliable-message-based-28wbpv35gt.pdf

Language support for fast and reliable message-based communication in singularity OS

. Singularity is a research project in Microsoft Research that started with the question: what would a software platform look like if it was designed from scratch with the primary goal of dependability? Singularity is working to answer this question by building on advances in programming languages and tools to develop a new system architecture and operating system (named Singularity), with the aim of producing a more robust and dependable software platform. Singularity demonstrates the practicality of new technologies and architectural decisions, which should lead to the construction of more robust and dependable systems.

/pdf/an-overview-of-the-singularity-project-1jdt28sajq.pdf

An Overview of the Singularity Project

In most modern operating systems, a process is a hardware-protected abstraction for isolating code and data. This protection, however, is selective. Many common mechanisms---dynamic code loading, run-time code generation, shared memory, and intrusive system APIs---make the barrier between processes very permeable. This paper argues that this traditional open process architecture exacerbates the dependability and security weaknesses of modern systems.As a remedy, this paper proposes a sealed process architecture, which prohibits dynamic code loading, self-modifying code, shared memory, and limits the scope of the process API. This paper describes the implementation of the sealed process architecture in the Singularity operating system, discusses its merits and drawbacks, and evaluates its effectiveness. Some benefits of this sealed process architecture are: improved program analysis by tools, stronger security and safety guarantees, elimination of redundant overlaps between the OS and language runtimes, and improved software engineering.Conventional wisdom says open processes are required for performance; our experience suggests otherwise. We present the first macrobenchmarks for a sealed-process operating system and applications. The benchmarks show that an experimental sealed-process system can achieve performance competitive with highly-tuned, commercial, open-process systems.

/pdf/sealing-os-processes-to-improve-dependability-and-safety-1swwo7n30k.pdf

Sealing OS processes to improve dependability and safety

Most operating systems enforce process isolation through hardware protection mechanisms such as memory segmentation, page mapping, and differentiated user and kernel instructions Singularity is a new operating system that uses software mechanisms to enforce process isolation A software isolated process (SIP) is a process whose boundaries are established by language safety rules and enforced by static type checking SIPs provide a low cost isolation mechanism that provides failure isolation and fast inter-process communicationTo compare the performance of Singularity's SIPs against traditional isolation techniques, we implemented an optional hardware isolation mechanism Protection domains are hardware-enforced address spaces, which can contain one or more SIPs Domains can either run at the kernel's privilege level or be fully isolated from the kernel and run at the normal application privilege level With protection domains, we can construct Singularity configurations that are similar to micro-kernel and monolithic kernel systems We found that hardware-based isolation incurs non-trivial performance costs (up to 25--33%) and complicates system implementation Software isolation has less than 5% overhead on these benchmarksThe lower run-time cost of SIPs makes their use feasible at a finer granularity than conventional processes However, hardware isolation remains valuable as a defense-in-depth against potential failures in software isolation mechanisms Singularity's ability to employ hardware isolation selectively enables careful balancing of the costs and benefits of each isolation technique

/pdf/deconstructing-process-isolation-1ru53i2u1t.pdf

Deconstructing process isolation

A software network bridge is disclosed which allows the connected network segments to be presented as a single network unit to the host computer. The software bridge can be implemented as an intermediate network driver, abstracting multiple network segments into a single network interface for higher level protocols and applications. While the intermediate network driver acts as a software bridge implementing the Spanning Tree Algorithm, it also acts a network interface driver to higher level protocols, conglomerating information from the multiple underlying network interface cards and forwarding along commands from the higher level software to the appropriate network interface card. The intermediate network driver can also simultaneously send the same data packet through multiple network interfaces by creating multiple packet descriptors, each pointing to the same data, but each given individually to the underlying network interfaces to control during their transmission. Further efficiencies can also be achieved by the software bridge, implemented as an intermediate network driver, through the use of a dynamic allocation scheme which increases the size of the useable buffers of each network interface without increasing the overall memory consumption, and the use of a queuing scheme which preliminarily examines incoming data packets to determine if any processing needs to be performed, and queues the packets should they require processing. Additionally, a user interface is presented exposing this functionality of the intermediate network driver.

Mark Aiken

Papers

Language support for fast and reliable message-based communication in singularity OS

An Overview of the Singularity Project

Sealing OS processes to improve dependability and safety

Deconstructing process isolation

Exposing a bridged network as a single virtual segment