Microkernel-based Operating Systems - Introduction Bjoern Doebel - PDF document

Faculty of Computer Science Institute for System Architecture, Operating Systems Group Microkernel-based Operating Systems - Introduction Bjoern Doebel Dresden, Oct 9 th 2007 Lecture Goals • Provide deeper understanding of OS mechanisms • Illustrate alternative design concepts • Promote OS research at TU Dresden • Make you all enthusiastic about OS development in general and microkernels in special TU Dresden, 2007-10-09 MOS - Introduction Slide 2 von 36 Administration - Lecture • Lecture every Tuesday, 1:00 PM, INF/E08 – First exception: No lecture next week. – Lecturers: Carsten Weinhold, Michael Roitzsch, Stefan Kalkowski, Marcus Völp, Björn Döbel • Slides: http://www.tudos.org -> Teaching -> Microkernel-based Operating Systems • Subscribe to our mailing list: http://os.inf.tu-dresden.de/mailman/listinfo/mos2007 • This lecture is not: Microkernel construction (in summer term) TU Dresden, 2007-10-09 MOS - Introduction Slide 3 von 36

Administration - Exercises • Exercises will be roughly bi-weekly, Wednesday, 2:50 PM, INF/E09 • Practical exercises in the computer pool • Paper reading exercises – Read a paper beforehand. – Sum it up and prepare 3 questions. – We expect you to actively participate in discussion. • First exercise will be paper reading on Oct 24 th : Per Brinch-Hansen “The nucleus of a multiprogramming system” TU Dresden, 2007-10-09 MOS - Introduction Slide 4 von 36 Complex lab • In parallel to this lecture there is a complex lab. • Groups of 2-3 students. • Build several components of an OS (memory server, keyboard driver, binary loader, ...) • “Komplexpraktikum” for (Media) Computer Science students • “Internship” for Computational Engineering • starts on Wednesday, Oct 10 th TU Dresden, 2007-10-09 MOS - Introduction Slide 5 von 36 Monolithic Operating Systems User Applications mode Device Scheduling Processes Drivers Kernel Network File ... mode Stacks Systems Hardware TU Dresden, 2007-10-09 MOS - Introduction Slide 6 von 36

What's the problem? • All system components run in privileged mode. • No isolation of components possible. – Faulty driver crashes the whole system. – More then 2/3 of today's systems are drivers. • No enforcement of good system design – can directly access all kernel data structures • Size and inflexibility – Not suitable for embedded systems. – Difficult to replace single components. • Increasing complexity becomes more and more difficult to manage. TU Dresden, 2007-10-09 MOS - Introduction Slide 7 von 36 One vision - microkernels • Minimal OS kernel – less error prone – small Trusted Computing Base – suitable for verification • System services implemented as user-level servers – flexible and extensible • Protection between individual components – systems get more • secure – inter-component protection • safe – crashing component does not (necessarily...) crash the whole system TU Dresden, 2007-10-09 MOS - Introduction Slide 8 von 36 One vision – microkernels (2) • Servers may implement multiple OS personalities • Servers may be configured to suit the target system (small embedded systems, desktop PCs, SMP systems, ...) • Enforce reasonable system design – Well-defined interfaces between components – No access to components besides these interfaces – Improved maintainability TU Dresden, 2007-10-09 MOS - Introduction Slide 9 von 36

Examples File Process • QNX kernel only system Manager contains QNX – IPC µkernel – Scheduling Network – IRQ redirection Device stack manager Partitions • LynxOS – “separation kernel” App A App A Security – combine secure and Policy App B real-time components System System System Services Services Services LynxOS Separation Kernel (Microkernel) Hardware TU Dresden, 2007-10-09 MOS - Introduction Slide 10 von 36 The mother of all microkernels • Mach – developed at CMU – designed as simple, extensible “communication kernel” – “ports” for communication channels and memory objects • Foundation for several real systems – Single Server Unix (BSD4.3 on Mach) – MkLinux (OSF) – IBM Workplace OS – Mac OS X • Shortcomings – performance – drivers still in the kernel TU Dresden, 2007-10-09 MOS - Introduction Slide 11 von 36 Mac OS X App Environments AWT, Swing Quick BSD Cocoa Carbon Time Quartz Window Manager JRE Application services User Core services JVM space Drivers, Mach BSD Kernel I/O kit Hardware TU Dresden, 2007-10-09 MOS - Introduction Slide 12 von 36

IBM Workplace OS • Main goals: – multiple OS personalities – run on multiple HW architectures Win Apps Unix Apps OS/2 Apps Windows Unix OS/2 Personality Personality Personality Network Processes Power ... Files OS base services Mach microkernel ARM PPC x86 MIPS Alpha TU Dresden, 2007-10-09 MOS - Introduction Slide 13 von 36 IBM Workplace OS (2) • Never finished • Failure causes: – Underestimated difficulties in creating OS personalities – Management errors, forced divisions to adopt new system without having a system – “Second System Effect”: too many fancy features – Too slow • Conclusion: Microkernel worked, but system atop the microkernel did not TU Dresden, 2007-10-09 MOS - Introduction Slide 14 von 36 Lessons learned • OS personalities did not work • Flexibility – but monolithic kernels became flexible, too (Linux kernel modules) • Better design – but monolithic kernels also improved (restricted symbol access, layered architectures) • Maintainability – still very complex • Performance matters a lot TU Dresden, 2007-10-09 MOS - Introduction Slide 15 von 36

Proved advantages • Subsystem protection / isolation • Code size – Fiasco kernel: < 15,000 lines of code – Minimal application: (boot loader + “hello world”): ~6,000 loc – Linux kernel (2.6.5, i386): 3.2 million loc (drivers: 1.9 million) • Customizable – Tailored memory management / scheduling / … algorithms – Adaptable to embedded / real-time / secure / … systems TU Dresden, 2007-10-09 MOS - Introduction Slide 16 von 36 Challenges • We need fast and efficient kernels – covered in the “Microkernel construction” lecture in the summer term • We need fast and efficient OS services – Memory and resource management – Synchronization – Device Drivers – File systems – Communication interfaces – subject of this lecture TU Dresden, 2007-10-09 MOS - Introduction Slide 17 von 36 Who's out there? • Minix @ FU Amsterdam (Tanenbaum) • Singularity @ MS Research • Eros/CoyotOS @ Johns Hopkins University • The L4 Microkernel Family – L4Ka::Hazelnut/Pistacchio – Uni Karlsruhe, Univ. of New South Wales (Sydney) – OKL4 – Open Kernel Labs – SeL4 – UNSW – Fiasco – TU Dresden – P4 – Sysgo AG TU Dresden, 2007-10-09 MOS - Introduction Slide 18 von 36

The L4 microkernel • Originally developed by Jochen Liedtke at IBM and GMD • 2 nd generation microkernel • Several kernel ABI versions: – L4.Fiasco: current stable version (Fiasco) – L4.X0: experimental, legacy (Fiasco, Hazelnut) – L4.X2, L4.V4: experimental / stable new API (Pistachio, Fiasco) – L4.sec: experimental capability support (Fiasco) – L4.v2: original Liedtke-compatible ABI version, now deprecated TU Dresden, 2007-10-09 MOS - Introduction Slide 19 von 36 L4 concepts • Jochen Liedtke: “A microkernel does no real work.” – kernel provides inevitable mechanisms – kernel does not enforce policies • But what is inevitable? – Abstractions • Threads • Address spaces (tasks) – Mechanisms • Communication • Mapping • Scheduling TU Dresden, 2007-10-09 MOS - Introduction Slide 20 von 36 L4 – Recursive Address spaces Application Application Application Pager 3 Pager 1 Pager 2 Physical Memory TU Dresden, 2007-10-09 MOS - Introduction Slide 21 von 36

L4 - Threads Address Space • Thread ::= Unit of Execution • Unique Thread ID • Properties managed by L4: – Instruction Pointer (EIP) Threads – Stack (ESP) Code – Registers • User-level applications need to Data – allocate stack memory – provide memory for application binary – find entry point Stack – ... Stack • 1 Address space can contain up to 128 threads TU Dresden, 2007-10-09 MOS - Introduction Slide 22 von 36 L4 - Communication • Synchronous inter-process communication (IPC) between threads – agreement between partners necessary – timeouts – no in-kernel buffering – efficient implementation necessary • IPC flavors: – send – receive_from (closed wait) – receive (open wait) – call (send and receive_from) – reply and wait (send and receive) TU Dresden, 2007-10-09 MOS - Introduction Slide 23 von 36 L4 IPC – Message types • short (register-only) IPC • fast – no memory access Thread A Thread B send(…) receive(…) EBX EBX EDX EDX TU Dresden, 2007-10-09 MOS - Introduction Slide 24 von 36