Singularity: Designing Beer Soware

James Larus Microso Research

CAV July 10, 2008 MSR’s Decade of Tools Progress (and Frustraon)

• MSR has researched, developed, and deployed programming tools for 10+ years • Struggle to bring tools to pracce – incomplete, informal specificaon – unsafe languages (C) – tenuous assumpons (e.g., code completely known and immutable) • Verificaon and tesng at a low level – language features and library APIs – persistent queson: “are these the right bugs?” • Soware development is inherently broken – “first we bug the soware, then we debug it” • People and organizaon may be more important than bugs and tesng – (another talk)

Singularity Singularity

• Microso Research project with goal of more robust and reliable soware Safe • Rethink the soware stack Languages (C#) • Arculated architectural principles – soware will fail, system should not – system should be self-describing Verification Tools – verify as many aspects as possible • No single magic bullet Improved OS Architecture – mutually reinforcing improvements to languages and compilers, systems, and tools

Singularity Singularity in the News

Judging from recent rumours, Unfortunately,that's this what willingness it is preparing to begin with to do.an entirely newEven foundation though isit notwon't located be withinin the WindowsWindows group but 7,in Microsoft’sMicrosoft research is happy arm, where scientiststo talk andabout their “ hereticalMinWin thoughts”—a are safely isolated.slimmed Last down April, Microsoftversion ofpublicly the unveiledWindows the five-year-old core. research It’s even project, willing called “Singularity.”to discus It is nothing its “Singularity” more than a neat project academic—a exercise, microkernel-based not a glimpse of Windows operating 7. system written strictly for “Singularityresearch is not the purposes. next Windows,” But ask said Rich Rashid, theabout company’s a project senior code-named vice president overseeing“Midori” research. and “Think everyone of it like clams a concept up. car.”

Singularity Why Rethink Soware Architecture?

VMS Windows (NT) Unix Linux Multics

1970 1980 1990 • Design parameters – scarce resources – assembly code – benign environment – knowledgeable users

Singularity The World Changed

• Hardware and soware industries were wildly successful – machines are fast, memory is cheap – computers are ubiquitous – safe, high-level languages • Malicious environment – ubiquitous worms, viruses, scams, aacks, …

• Few users understand computers or soware

Singularity Key Singularity Tenets

1. Use safe (managed) programming languages everywhere – safe ⇒ type safe and memory safe (C# or Java) – everywhere ⇒ applicaons, extensions, OS services, device drivers, kernel, … 2. Improve system resilience in the face of soware errors – failure containment boundaries – explicit failure noficaon model 3. Modular verificaon – design assuming automated analysis – seal environments so verificaon can be sound – make system “self-describing,” so pieces can be examined in isolaon – specify and check behavior at many levels of abstracon

Singularity

Deemphasize Performance

• Easy to measure, but less important than dependability

• “Good enough” performance was goal – Singularity has very good performance

Singularity Singularity OS Architecture channels • Safe micro-kernel content web TCP/IP network – 95% wrien in C# extension server stack driver – all services and drivers in processes

ext. server tcp driver • Soware isolated processes (SIPs) class class class class – all user code is verifiably safe library library library library processes – some unsafe code in trusted runme runme runme runme runme – processes and kernel sealed at execuon • Communicaon via channels kernel API – channel behavior is specified and checked kernel – fast and efficient communicaon kernel page mgr scheduler class • Working research prototype chan mgr library – not Windows replacement proc mgr i/o mgr runme – shared source download HAL

Singularity SIP Process Model

• Process contains only safe code – except language runme (GC) • No shared memory – communicate via messages Software • Messages flow over bi-direconal Isolated channels Process – well-defined & verifiable “SIP” • Small, versioned interface to kernel – threads, memory, & channels ABI • Seal process on execuon – no dynamic code loading Kernel – no in-process plug-ins

Singularity Challenge 1: Pervasive Safe Languages

• Modern, safe programming languages – preclude enre categories of serious defects, e.g. buffer overruns – easier to analyze • Singularity is wrien in Spec# – C# + pre/post-condions and invariants • Language research to support Singularity abstracons – channel communicaons – factor libraries into composable pieces – compile-me reflecon • Nave compiler and runme system – no bytecodes or MSIL (not JVM or CLR)

Singularity Runme System

• JVM & CLR not appropriate for building systems • Rich runme (“one size fits all”) – monolithic, general-purpose environment – large memory footprint (~4 MB/process for CLR) – many OS dependencies (CLR PAL requires >300 Win32 APIs) • JIT compiler – increases runme size and complexity – unpredictable performance • Replicate OS funconality – security, threading, configuraon, etc.

Singularity Singularity Runme

Singularity Applicaon • Minimal run-me system Runme Libraries (GC, etc.) • Ahead-of-me, global opmizing compiler (Bartok) – specializes runme and libraries – eliminate unused language features and Bartok applicaon or library code Compiler • Factorable runme and libraries • Language runme, garbage collector, and libraries selectable on per-process basis – reduce memory and computaon overhead Singularity Process – enforce design discipline and system policies per process x86 Executable

Singularity Challenge 2: Improve Resilience

• Cannot build soware without defects – verificaon is a chimera (but we could do a lot beer) • Soware defects should not cause system failure • A resilient system architecture should – isolate system components to prevent data corrupon – provide clear failure noficaon – implement policy for restarng failed component • Exisng system architectures lack isolaon and resilience

Singularity Open Process Architecture

• Ubiquitous (Windows, Unix, Java, browsers, etc.) Process – DLLs, classes, plug-ins, device drivers, etc. • Processes are not sealed – dynamic code loading and runme code generaon – shared memory – system API allow process to alter another’s state • Low dependability – 85% of Windows crashes caused by third party code in kernel – interface between host and extension oen poorly documented and understood – maintenance nightmare

Singularity Single Process Architecture

• Tradional safe language architecture App – Xerox PARC (Cedar, Smalltalk, etc.) App and Lisp Machine model – Java and .NET as well OS • Tangled code and data – language safety provides some isolaon – garbage collecon must reclaim resources – dynamic code loading and runme code generaon – runme is single point of failure Runtime

Singularity Singularity Sealed Processes

• Singularity processes are sealed – no dynamic code loading or run-me Extension code generaon Process • all code present when process starts execuon – extensions execute in disnct Extension processes • separate closed environments with well-defined interfaces – no shared memory

Kernel • Fundamental unit of failure isolaon • Enhance opmizaon, verificaon, security – “closed world” assumpon is true!

Singularity Program Opmizaon

Code Code w/ Program Whole Tree Shake % Reduction Kernel 2,371 KB 1,291 KB 46%

Web Server 2,731 KB 765 KB 72%

SPECweb99 Plug-in 2,144 KB 502 KB 77%

IDE Disk Driver 1,846 KB 455 KB 75%

• Closed world allows global opmizaon to eliminate unused code • Reduces process code size by up to 75% • Fewer code paths ⇒ beer opmizaon & error analysis

Singularity Complexity of Extensions

• Move register allocator Bartok Compiler from Bartok compiler to bartok.exe separate process Register Allocator – one of 50 phases regalloc.dll – updates IR to assign registers and insert spill operaons – 156 shared classes (IR + ISA) – invoked per funcon Register Allocator regalloc.exe • 6,441 calls in kernel compile • 50KB to 1.5MB of data

EuroSys 2007 Sealing OS Processes to Improve Dependability and 19 Security Code Complexity

Code Lines % of Orig. Bartok Compiler 210,000 95.45% Register Allocator 10,000 4.55% Altered in Host 3 +0.00%

Limited Marshal Tags 107 +0.05% Channel and Child 400 +0.18% Total 220,510 100.25%

• Child process adds < .25% (508 lines) to code base • Time to compile Singularity kernel increases by 11%

EuroSys 2007 Sealing OS Processes to Improve Dependability and 20 Security Isolaon Requires Lightweight Processes

• Tradional processes rely on virtual memory and hardware domains – legacy of assembly language era – VM prevents reference into other address spaces – protecon prevents unprivileged code from access system resources • Processes are expensive to create and schedule – high cost to cross protecon domains (rings), handle TLB misses, and manipulate address spaces • Costs encourages monolithic architecture – expensive process creaon and inter-process communicaon – large, undifferenated applicaons – dynamically loaded extensions

Singularity Soware Isolated Processes (SIPs)

• Protecon and isolaon enforced by language safety and kernel API design – process has exclusive access to a set of pages – all of process’s objects reside on its pages (object space, not address space) – language safety ensures process can’t create or mutate reference to other pages – everything can run in ring 0 in kernel memory (without the MMU)! • Global invariants: – no process contains a pointer to another process’s object space – no pointers from exchange heap into process

P1 P2 P3

Singularity Interprocess Communicaons

• Channels are strongly typed (value & behavior), bidireconal communicaons ports – messages passing with language support • Messages live outside processes (“exchange heap”) – only a single reference to a message • “Mailbox” semancs enforced by linear types – copying and pointer passing are semancally indisnguishable • Channel buffers pre-allocated according to contract

P1 P2 P3

exchange heap

Singularity Performance Micro Benchmarks

Athlon64 3000+ Cost (CPU Cycles) (1.8GHz) Linux 2.6.11 Windows XP Singularity FreeBSD 5.3 nForce4 SLI (Red Hat FC4) (SP2) Minimum kernel API 80 878 437 627 call Message 13,300 5,800 6,340 request/reply 1,041 Process 388,000 1,030,000 719,000 5,380,000 create & start

• Why? – stac verificaon replaces hardware protecon – all SIPs run in ring 0 – good opmizing compiler (not JIT) Singularity OS Controls Resources and Security

• OS owns, allocates, and reclaims system resources – convenonal model • On process terminaon, OS reclaims memory pages and channels – not dependent on finalizaon or garbage collecon • Clean failure noficaon – messages in channel sll available to other process • Security policy on per-process – crux is control of channels (capabilies)

Singularity Would You Trust Your System to a Type System?

• Process integrity depends on type and memory safety – currently trust compiler and runme • TAL can remove compiler from trusted compung base • Need to verify GC and runme as well (research challenge)

Sing# csc TALSingularity TCB Singularity TCB C# SingularitySingularity MSIL+ bartok x86 source sgc system system

compiler byte code applicaon verificaon verificaon verificaon

Singularity Sll Not Convinced?

• Hardware Protecon Domains – virtual address space – contains one or more SIPs – runs at ring 0 (“kernel domain”) or ring 3

27 Domains: Monolithic Kernel

App App App 1 2 3

SIP

Protection Domain File Net System Stack Ring 3

Ring 0 Kernel

28 Domains: Novel Models

Unsigned App2 SIP Protection Domain

Unsigned Ring 3 Signed Extension App1 Extension Ring 0

Signed Unsigned Kernel Driver Driver

29 Hardware is Costly

Webfiles Macrobenchmark Unsafe Code Tax

+37.7% +33.0% 1.40 Safe Code Tax +18.9% 1.20 +6.3% -4.7% 1.00

0.80

0.60

0.40

0.20

0.00 No runtime Physical Add VM Add Separate Add Ring 3 Full Microkernel checks Memory Address Space Challenge 3: Verify More channels • Process internals (code): content web TCP/IP network – type safety extension server stack driver

– object invariants ext. server tcp driver – method pre- & post- condions class class class class library library library library – component interfaces processes runme runme runme runme • Process externals: – channel contracts Kernel API – resource access & dependencies kernel • System: kernel page mgr – communicaon safety scheduler class chan mgr library – hardware resource conflict free proc mgr i/o mgr runme – namespace conflict free HAL

Singularity Boogie and Singularity

Network device driver Scheduler (kernel) • Hardware interacons • Global properes – Registers, DMA, etc. – Interrupts, lock levels, etc. • Layered objects • Strongly coupled objects – Main object owns others – Many object references • Driven by WDF interface • Concurrent – Order of invocaons – Interrupts, multhreading Use Boogie to verify interesting properties in both contexts (Kevin Bierhoff 2007) 32 Example: Channel Contracts

public contract IoStream { Open? -> Error! ... Start state Start : { Open? -> { OK! -> Opened; Error! -> End; Open? -> OK! } End } state Opened : { Read? -> Data! -> Opened; Write? -> OK! -> Opened; Opened Close? -> OK! Close? -> OK! -> End; } state End; ... Read? -> Data! } Write? -> OK! ? = receive ! = send Singularity Example: Contract Conformance

Contract Web Server (User) public contract TcpSocketContract { ...... conn.SendRead(); state Connected : { switch receive { Read? -> ReadResultPending; case conn.Data(readData) : Write? -> WriteResultPending;

dataBuffer.AddToTail(readData); GetLocalAddress? -> IPAddress! return true; -> Connected; GetLocalPort? -> Port! -> Connected; case conn.RemoteClose() : return false; DoneSending? -> ReceiveOnly; } DoneReceiving? -> SendOnly; ... Close? -> Closed; Abort? -> Closed; } Missing Case state ReadResultPending : { case conn.NoMoreData() : Data! -> Connected; NoMoreData! -> SendOnly; RemoteClose! -> Zombie; }

Singularity Example: Configuraon Specificaons requires PCI Device [DriverCategory] [Signature("/pci/03/00/5333/8811")] class S3Trio64Config : DriverCategoryDeclaration requires 4MB frame buffer { (from in PCI config) [IoMemoryRange(0, Length = 0x400000)] IoMemoryRange frameBuffer; requires system console buffer [IoFixedMemoryRange(Base = 0xb8000, Length = 0x8000)] IoMemoryRange textBuffer; requires VGA I/O ports ...

[IoFixedPortRange(Base = 0x3c0, Length = 0x20)] requires control by IoPortRange control; plug-and-play system [ExtensionEndpoint(typeof(ExtensionContract.Exp))] TRef pnp;

[ServiceEndpoint(typeof(VideoDeviceContract.Exp))] TRef video; Provides video ... capability to system

Singularity Specificaon Usable in Many Ways

Driver (Source + Spec) File Disk Driver System driver class Driver Manifest library runme 1. Load driver

Conflict 2. Allocate I/O objects kernel kernel page mgr 3. Create channels scheduler class chan mgr library proc mgr System i/o mgr runme Manifest HAL

Singularity Architecture & Verificaon

• Soware architecture can enhance verificaon – modern programming language with appropriate abstracons – sealed processes – explicit communicaons across typed channels – specificaons throughout system • Verificaon community should be involved in system design – your insights and contribuons can make soware beer (e.g. TM) – improved reliability and robustness are achievable – “verify what they build” approach complicates verificaon and produces poor soware • Challenge: make reliability and robustness more important than performance

Singularity Conclusion

• Can we fundamentally improve the dependability of soware? (yes) • Reexamine and rethink language, OS, and system architecture assumpons – OS should control applicaon’s execuon environment – new mechanisms to enhance system integrity, verifiability, and dependability • Programming languages and runme systems are central to new architecture • Singularity is a complete (but simple) system – safe languages all the way down to the hardware – OS architecture improves system integrity and verificaon – many more aspects of system behavior are verifiable • Singularity project is done – using Singularity in small computer (cPhone) – working with incubaon team that is expanding Singularity

Singularity Obtaining Singularity

• Info: – hp://research.microso.com/os/singularity

• Code: – hp://www.codeplex.com/singularity

Singularity Singularity Research Team

• Lead by Galen Hunt and Jim Larus • MSR Cambridge – Paul Barham, Richard Black, Tim Harris, Rebecca Isaacs, Dushyanth Narayanan • MSR Redmond – Advanced Compiler Technology Group: • Juan Chen, Qunyan Mangus, Mark Plesko, Bjarne Steensgaard, David Tardi – Foundaons of Soware Engineering Group: • Wolfgang Grieskamp – Operang Systems Group: • Mark Aiken, Chris Hawblitzel, Orion Hodson, Galen Hunt, Steven Levi – Security and Distributed Systems: • Dan Simon, Brian Zill – Soware Design and Implementaon Group: • John DeTreville, Ben Zorn – Soware Improvement Group: • Manuel Fahndrich, James Larus, Sriram Rajamani, Jakob Rehof • MSR Silicon Valley – Marn Abadi, Andrew Birrell, Ulfar Erlingsson, Roy Levin, Nick Murphy, Ted Wobber

Singularity