Singularity: Designing Beer So3ware James Larus Microso. Research CAV July 10, 2008 MSR’s Decade of Tools Progress (and Frustra?on) • MSR has researched, developed, and deployed programming tools for 10+ years • Struggle to bring tools to pracFce – incomplete, informal specificaon – unsafe languages (C) – tenuous assumpFons (e.g., code completely known and immutable) • Verificaon and tesFng at a low level – language features and library APIs – persistent quesFon: “are these the right bugs?” • So.ware development is inherently broken – “first we bug the so.ware, then we debug it” • People and organizaon may be more important than bugs and tesFng – (another talk) Singularity Singularity • Microso. Research project with goal of more robust and reliable so.ware Safe • Rethink the so.ware stack Languages (C#) • ArFculated architectural principles – so.ware 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 So3ware 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 so.ware 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 so.ware 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 so.ware errors – failure containment boundaries – explicit failure noFficaon 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 abstracFon 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% wri[en in C# extension server stack driver – all services and drivers in processes ext. server tcp driver • So.ware isolated processes (SIPs) class class class class – all user code is verifiably safe library library library library processes – some unsafe code in trusted runFme runFme runFme runFme runFme – processes and kernel sealed at execuFon • 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 runFme – shared source download HAL Singularity SIP Process Model • Process contains only safe code – except language runFme (GC) • No shared memory – communicate via messages Software • Messages flow over bi-direcFonal Isolated channels Process – well-defined & verifiable “SIP” • Small, versioned interface to kernel – threads, memory, & channels ABI • Seal process on execuFon – no dynamic code loading Kernel – no in-process plug-ins Singularity Challenge 1: Pervasive Safe Languages • Modern, safe programming languages – preclude enFre categories of serious defects, e.g. buffer overruns – easier to analyze • Singularity is wri[en in Spec# – C# + pre/post-condiFons and invariants • Language research to support Singularity abstracFons – channel communicaons – factor libraries into composable pieces – compile-me reflecon • Nave compiler and runFme system – no bytecodes or MSIL (not JVM or CLR) Singularity Run?me System • JVM & CLR not appropriate for building systems • Rich runFme (“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 runFme size and complexity – unpredictable performance • Replicate OS funcFonality – security, threading, configuraon, etc. Singularity Singularity Run?me Singularity Applicaon • Minimal run-Fme system RunFme Libraries (GC, etc.) • Ahead-of-Fme, global opFmizing compiler (Bartok) – specializes runFme and libraries – eliminate unused language features and Bartok applicaon or library code Compiler • Factorable runFme and libraries • Language runFme, 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 so.ware without defects – verificaon is a chimera (but we could do a lot be[er) • So.ware defects should not cause system failure • A resilient system architecture should – isolate system components to prevent data corrupFon – provide clear failure noFficaon – implement policy for restarFng failed component • ExisFng 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 runFme 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 o.en poorly documented and understood – maintenance nightmare Singularity Single Process Architecture • TradiFonal 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 collecFon must reclaim resources – dynamic code loading and runFme code generaon – runFme is single point of failure Runtime Singularity Singularity Sealed Processes • Singularity processes are sealed – no dynamic code loading or run-Fme Extension code generaon Process • all code present when process starts execuFon – extensions execute in disFnct Extension processes • separate closed environments with well-defined interfaces – no shared memory Kernel • Fundamental unit of failure isolaon • Enhance opFmizaon, verificaon, security – “closed world” assumpFon 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 opFmizaon to eliminate unused code • Reduces process code size by up to 75% • Fewer code paths ⇒ be[er opFmizaon & 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 Isola?on Requires Lightweight Processes • TradiFonal processes rely on virtual memory and hardware domains – legacy of assembly language era – VM prevents reference into other address spaces – protecFon prevents unprivileged code from access system resources • Processes are expensive to create and schedule – high cost to cross protecFon domains (rings), handle TLB misses, and manipulate address spaces • Costs encourages monolithic architecture – expensive process creaon and inter-process communicaon – large, undifferenFated applicaons – dynamically loaded extensions Singularity Soware Isolated Processes (SIPs) • ProtecFon 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