Singularity: Designing Be1er So3ware

Transcription

1 : Designing Be1er So3ware James Larus Microso. Research CAV July 10, 2008

2 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 specificafon unsafe languages (C) tenuous assumpfons (e.g., code completely known and immutable) VerificaFon 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 organizafon may be more important than bugs and tesfng (another talk)

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

4 in the News Judging from recent rumours, Unfortunately, that's this what willingness it is preparing to begin with to do. an entirely new Even foundation though is it not won't located be within in the Windows Windows group but 7, in Microsoft s research is happy arm, where scientists to talk and about their MinWin a heretical thoughts are safely isolated. slimmed Last down April, Microsoft version of publicly the unveiled Windows the five-year-old core. research It s even project, willing called. to discus It nothing its more than a neat project academic a exercise, microkernel-based not a glimpse of Windows operating 7. system written strictly for research is not the purposes. next Windows, But ask said Rich Rashid, the about company s a project senior code-named vice president overseeing Midori research. and Think everyone of it like clams a concept up. car.

5 Why Rethink So3ware Architecture? Multics Unix VMS Windows (NT) Linux Design parameters scarce resources assembly code benign environment knowledgeable users

6 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, a[acks, Few users understand computers or so.ware

7 Key Tenets 1. Use safe (managed) programming languages everywhere safe type safe and memory safe (C# or Java) everywhere applicafons, extensions, OS services, device drivers, kernel, 2. Improve system resilience in the face of so.ware errors failure containment boundaries explicit failure nofficafon model 3. Modular verificafon design assuming automated analysis seal environments so verificafon can be sound make system self- describing, so pieces can be examined in isolafon specify and check behavior at many levels of abstracfon

8 Deemphasize Performance Easy to measure, but less important than dependability Good enough performance was goal has very good performance

9 OS Architecture channels content extension web server TCP/IP stack network driver Safe micro- kernel 95% wri[en in C# all services and drivers in processes processes ext. class library runfme server class library runfme tcp class library runfme driver class library runfme So.ware isolated processes (SIPs) all user code is verifiably safe some unsafe code in trusted runfme processes and kernel sealed at execufon kernel API CommunicaFon via channels channel behavior is specified and checked kernel page mgr scheduler chan mgr proc mgr i/o mgr kernel class library runfme fast and efficient communicafon Working research prototype not Windows replacement shared source download HAL

10 SIP Process Model Process contains only safe code except language runfme (GC) No shared memory communicate via messages Software Isolated Process SIP Kernel ABI Messages flow over bi- direcfonal channels well- defined & verifiable Small, versioned interface to kernel threads, memory, & channels Seal process on execufon no dynamic code loading no in- process plug- ins

11 Modern, safe programming languages Challenge 1: Pervasive Safe Languages preclude enfre categories of serious defects, e.g. buffer overruns easier to analyze is wri[en in Spec# C# + pre/post- condifons and invariants Language research to support abstracfons channel communicafons factor libraries into composable pieces compile- Fme reflecfon NaFve compiler and runfme system no bytecodes or MSIL (not JVM or CLR)

12 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, configurafon, etc.

13 Run?me RunFme (GC, etc.) ApplicaFon Libraries Minimal run- Fme system Ahead- of- Fme, global opfmizing compiler (Bartok) specializes runfme and libraries Bartok Compiler eliminate unused language features and applicafon or library code Factorable runfme and libraries Process x86 Executable Language runfme, garbage collector, and libraries selectable on per- process basis reduce memory and computafon overhead enforce design discipline and system policies per process

14 Challenge 2: Improve Resilience Cannot build so.ware without defects verificafon 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 nofficafon implement policy for restarfng failed component ExisFng system architectures lack isolafon and resilience

15 Open Process Architecture Process Ubiquitous (Windows, Unix, Java, browsers, etc.) DLLs, classes, plug- ins, device drivers, etc. Processes are not sealed dynamic code loading and runfme code generafon 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

16 Single Process Architecture App OS Runtime App TradiFonal safe language architecture Xerox PARC (Cedar, Smalltalk, etc.) and Lisp Machine model Java and.net as well Tangled code and data language safety provides some isolafon garbage collecfon must reclaim resources dynamic code loading and runfme code generafon runfme is single point of failure

17 Sealed Processes Process Kernel Extension Extension processes are sealed no dynamic code loading or run- Fme code generafon all code present when process starts execufon extensions execute in disfnct processes separate closed environments with well- defined interfaces no shared memory Fundamental unit of failure isolafon Enhance opfmizafon, verificafon, security closed world assumpfon is true!

18 Program Op?miza?on Program Code Whole Closed world allows global opfmizafon to eliminate unused code Reduces process code size by up to 75% Fewer code paths be[er opfmizafon & error analysis Code w/ 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%

19 Complexity of Extensions Move register allocator from Bartok compiler to separate process one of 50 phases updates IR to assign registers and insert spill operafons 156 shared classes (IR + ISA) invoked per funcfon 6,441 calls in kernel compile 50KB to 1.5MB of data Bartok Compiler bartok.exe Register Allocator regalloc.dll Register Allocator regalloc.exe EuroSys 2007 Sealing OS Processes to Improve Dependability and Security 19

20 Code Complexity Code Lines % of Orig. Bartok Compiler 210, % Register Allocator 10, % Altered in Host % Limited Marshal Tags % Channel and Child % Total 220, % Child process adds <.25% (508 lines) to code base Time to compile kernel increases by 11% EuroSys 2007 Sealing OS Processes to Improve Dependability and 20 Security

21 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 creafon and inter- process communicafon large, undifferenfated applicafons dynamically loaded extensions

22 So3ware Isolated Processes (SIPs) ProtecFon and isolafon 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

23 Interprocess Communica?ons Channels are strongly typed (value & behavior), bidirecfonal communicafons ports messages passing with language support Messages live outside processes ( exchange heap ) only a single reference to a message Mailbox semanfcs enforced by linear types copying and pointer passing are semanfcally indisfnguishable Channel buffers pre- allocated according to contract P1 P2 P3 exchange heap

24 Performance Micro Benchmarks Athlon (1.8GHz) nforce4 SLI FreeBSD 5.3 Cost (CPU Cycles) Linux (Red Hat FC4) Windows XP (SP2) Minimum kernel API call Message request/reply 1,041 13,300 5,800 6,340 Process create & start 388,000 1,030, ,000 5,380,000 Why? stafc verificafon replaces hardware protecfon all SIPs run in ring 0 good opfmizing compiler (not JIT)

25 OS Controls Resources and Security OS owns, allocates, and reclaims system resources convenfonal model On process terminafon, OS reclaims memory pages and channels not dependent on finalizafon or garbage collecfon Clean failure nofficafon messages in channel sfll available to other process Security policy on per- process crux is control of channels (capabilifes)

26 Would You Trust Your System to a Type System? Process integrity depends on type and memory safety currently trust compiler and runfme TAL can remove compiler from trusted compufng base Need to verify GC and runfme as well (research challenge) Sing# C# source csc sgc MSIL+ bartok TAL TCB TCB x86 system compiler verificafon byte code verificafon applicafon verificafon

27 S?ll Not Convinced? Hardware ProtecFon Domains virtual address space contains one or more SIPs runs at ring 0 ( kernel domain ) or ring 3 27

28 Domains: Monolithic Kernel App 1 App 2 App 3 File System Kernel Net Stack SIP Protection Domain Ring 3 Ring 0 28

29 Domains: Novel Models Unsigned App2 SIP Protection Domain App1 Signed Extension Unsigned Extension Ring 3 Ring 0 Unsigned Driver Signed Driver Kernel 29

30 Hardware is Costly Webfiles Macrobenchmark Unsafe Code Tax Safe Code Tax -4.7% +6.3% +18.9% +33.0% +37.7% No runtime checks Physical Memory Add VM Add Separate Address Space Add Ring 3 Full Microkernel

31 Challenge 3: Verify More channels processes content extension ext. class library Kernel API runfme web server server class library runfme kernel page mgr scheduler chan mgr proc mgr i/o mgr HAL TCP/IP stack tcp class library runfme kernel class library runfme network driver driver class library runfme Process internals (code): type safety object invariants method pre- & post- condifons component interfaces Process externals: channel contracts resource access & dependencies System: communicafon safety hardware resource conflict free namespace conflict free

32 Boogie and Network device driver Hardware interacfons Registers, DMA, etc. Layered objects Main object owns others Driven by WDF interface Scheduler (kernel) Global properfes Interrupts, lock levels, etc. Strongly coupled objects Many object references Concurrent Order of invocafons Interrupts, mulfthreading Use Boogie to verify interesting properties in both contexts (Kevin Bierhoff 2007) 32

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

34 Example: Contract Conformance Contract public contract TcpSocketContract {... state Connected : { Read? -> ReadResultPending; Write? -> WriteResultPending; } GetLocalAddress? -> IPAddress! -> Connected; GetLocalPort? -> Port! -> Connected; DoneSending? -> ReceiveOnly; DoneReceiving? -> SendOnly; Close? -> Closed; Abort? -> Closed; state ReadResultPending : { Data! -> Connected; NoMoreData! -> SendOnly; RemoteClose! -> Zombie; }... conn.sendread(); switch receive { case conn.data(readdata) : }... Web Server (User) databuffer.addtotail(readdata); return true; case conn.remoteclose() : return false; Missing Case case conn.nomoredata() :

35 Example: [DriverCategory] [Signature("/pci/03/00/5333/8811")] Configura?on Specifica?ons class S3Trio64Config : DriverCategoryDeclaration { [IoMemoryRange(0, Length = 0x400000)] IoMemoryRange framebuffer; requires PCI Device requires 4MB frame buffer (from in PCI config) requires system console buffer [IoFixedMemoryRange(Base = 0xb8000, Length = 0x8000)] IoMemoryRange textbuffer; requires VGA I/O ports... [IoFixedPortRange(Base = 0x3c0, Length = 0x20)] IoPortRange control; [ExtensionEndpoint(typeof(ExtensionContract.Exp))] TRef<ExtensionContract.Exp:Start> pnp; [ServiceEndpoint(typeof(VideoDeviceContract.Exp))] TRef<ServiceProviderContract.Exp:Start> video;... requires control by plug-and-play system Provides video capability to system

36 Specifica?on Usable in Many Ways Conflict Driver (Source + Spec) Driver Manifest System Manifest 1. Load driver 2. Allocate I/O objects 3. Create channels File System Disk Driver driver class library runfme kernel page mgr scheduler chan mgr proc mgr i/o mgr HAL kernel class library runfme

37 Architecture & Verifica?on So.ware architecture can enhance verificafon modern programming language with appropriate abstracfons sealed processes explicit communicafons across typed channels specificafons throughout system VerificaFon community should be involved in system design your insights and contribufons can make so.ware be[er (e.g. TM) improved reliability and robustness are achievable verify what they build approach complicates verificafon and produces poor so.ware Challenge: make reliability and robustness more important than performance

38 Conclusion Can we fundamentally improve the dependability of so3ware? (yes) Reexamine and rethink language, OS, and system architecture assumpfons OS should control applicafon s execufon environment new mechanisms to enhance system integrity, verifiability, and dependability Programming languages and runfme systems are central to new architecture is a complete (but simple) system safe languages all the way down to the hardware OS architecture improves system integrity and verificafon many more aspects of system behavior are verifiable project is done using in small computer (cphone) working with incubafon team that is expanding

39 Obtaining Info: h[p://research.microso..com/os/singularity Code: h[p://

40 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 TardiF FoundaFons of So.ware Engineering Group: Wolfgang Grieskamp OperaFng Systems Group: Mark Aiken, Chris Hawblitzel, Orion Hodson, Galen Hunt, Steven Levi Security and Distributed Systems: Dan Simon, Brian Zill So.ware Design and ImplementaFon Group: John DeTreville, Ben Zorn So.ware Improvement Group: Manuel Fahndrich, James Larus, Sriram Rajamani, Jakob Rehof MSR Silicon Valley MarFn Abadi, Andrew Birrell, Ulfar Erlingsson, Roy Levin, Nick Murphy, Ted Wobber