Lecture Goals Faculty of Computer Science Institute for System Architecture, Operating Systems Group • Provide deeper understanding of OS mechanisms • Illustrate alternative design concepts Microkernel-based Operating Systems - Introduction • Promote OS research at TU Dresden Bjoern Doebel • Make you all enthusiastic about OS development in general and microkernels in special Dresden, Oct 9th 2007 TU Dresden, 2007-10-09 MOS - Introduction Slide 2 von 36 Administration - Lecture Administration - Exercises • Lecture every Tuesday, 1:00 PM, INF/E08 • Exercises will be roughly bi-weekly, – First exception: No lecture next week. Wednesday, 2:50 PM, INF/E09 – Lecturers: Carsten Weinhold, Michael Roitzsch, • Practical exercises in the computer pool Stefan Kalkowski, Marcus Völp, Björn Döbel • Paper reading exercises • Slides: http://www.tudos.org -> Teaching -> – Read a paper beforehand. Microkernel-based Operating Systems – Sum it up and prepare 3 questions. • Subscribe to our mailing list: – We expect you to actively participate in http://os.inf.tu-dresden.de/mailman/listinfo/mos2007 discussion. • First exercise will be paper reading on • This lecture is not: Microkernel construction Oct 24th: Per Brinch-Hansen “The nucleus of a (in summer term) multiprogramming system” TU Dresden, 2007-10-09 MOS - Introduction Slide 3 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 4 von 36 Complex lab Monolithic Operating Systems • In parallel to this lecture there is a complex lab. User • Groups of 2-3 students. Applications mode • Build several components of an OS (memory server, keyboard driver, binary loader, ...) Device Scheduling Processes • “Komplexpraktikum” for (Media) Computer Drivers Science students Kernel Network File ... • “Internship” for Computational Engineering Stacks Systems mode • starts on Wednesday, Oct 10th Hardware TU Dresden, 2007-10-09 MOS - Introduction Slide 5 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 6 von 36 What's the problem? One vision - microkernels • All system components run in privileged • Minimal OS kernel mode. – less error prone • No isolation of components possible. – small Trusted Computing Base – Faulty driver crashes the whole system. – suitable for verification – More then 2/3 of today's systems are drivers. • System services implemented as user-level • No enforcement of good system design servers – can directly access all kernel data structures – flexible and extensible • Size and inflexibility • Protection between individual components – Not suitable for embedded systems. – systems get more – Difficult to replace single components. • secure – inter-component protection • Increasing complexity becomes more and • safe – crashing component does not more difficult to manage. (necessarily...) crash the whole system TU Dresden, 2007-10-09 MOS - Introduction Slide 7 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 8 von 36 One vision – microkernels (2) Examples File Process • Servers may implement multiple OS • QNX kernel only system Manager personalities contains – IPC QNX • Servers may be configured to suit the target µkernel – Scheduling system (small embedded systems, desktop Network PCs, SMP systems, ...) – IRQ redirection Device stack manager • Enforce reasonable system design – Well-defined interfaces between components Partitions – No access to components besides these • LynxOS interfaces – “separation kernel” App A App A Security – Improved maintainability – combine secure and App B Policy real-time components System System System Services Services Services LynxOS Separation Kernel (Microkernel) TU Dresden, 2007-10-09 MOS - Introduction Slide 9 von 36 TU Dresden, 2007-10-09 MOS - Introduction Hardware Slide 10 von 36 The mother of all microkernels Mac OS X • Mach – developed at CMU – designed as simple, extensible “communication App Environments AWT, Swing Quick kernel” BSD Cocoa Carbon Time – “ports” for communication channels and Quartz Window Manager memory objects JRE • Foundation for several real systems Application services – Single Server Unix (BSD4.3 on Mach) – MkLinux (OSF) User – IBM Workplace OS Core services JVM space – Mac OS X Drivers, • Shortcomings Mach BSD I/O kit Kernel – performance – drivers still in the kernel Hardware TU Dresden, 2007-10-09 MOS - Introduction Slide 11 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 12 von 36 IBM Workplace OS IBM Workplace OS (2) • Main goals: • Never finished – multiple OS personalities • Failure causes: – run on multiple HW architectures – Underestimated difficulties in creating OS Win Apps Unix Apps OS/2 Apps personalities – Management errors, forced divisions to adopt Windows Unix OS/2 Personality Personality Personality new system without having a system – “Second System Effect”: too many fancy Network Processes Power ... features Files OS base services – Too slow • Conclusion: Microkernel worked, but system Mach microkernel atop the microkernel did not ARM PPC x86 MIPS Alpha TU Dresden, 2007-10-09 MOS - Introduction Slide 13 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 14 von 36 Lessons learned Proved advantages • OS personalities did not work • Subsystem protection / isolation • Flexibility – but monolithic kernels became • Code size flexible, too (Linux kernel modules) – Fiasco kernel: < 15,000 lines of code • Better design – but monolithic kernels also – Minimal application: (boot loader + “hello improved (restricted symbol access, layered world”): ~6,000 loc architectures) – Linux kernel (2.6.5, i386): 3.2 million loc • Maintainability – still very complex (drivers: 1.9 million) • Performance matters a lot • Customizable – Tailored memory management / scheduling / … algorithms – Adaptable to embedded / real-time / secure / … systems TU Dresden, 2007-10-09 MOS - Introduction Slide 15 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 16 von 36 Challenges Who's out there? • We need fast and efficient kernels • Minix @ FU Amsterdam (Tanenbaum) – covered in the “Microkernel construction” • Singularity @ MS Research lecture in the summer term • Eros/CoyotOS @ Johns Hopkins University • We need fast and efficient OS services • The L4 Microkernel Family – Memory and resource management – L4Ka::Hazelnut/Pistacchio – Uni Karlsruhe, – Synchronization Univ. of New South Wales (Sydney) – Device Drivers – OKL4 – Open Kernel Labs – File systems – SeL4 – UNSW – Communication interfaces – Fiasco – TU Dresden – subject of this lecture – P4 – Sysgo AG TU Dresden, 2007-10-09 MOS - Introduction Slide 17 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 18 von 36 The L4 microkernel L4 concepts • Originally developed by Jochen Liedtke at IBM • Jochen Liedtke: “A microkernel does no real and GMD work.” • 2nd generation microkernel – kernel provides inevitable mechanisms • Several kernel ABI versions: – kernel does not enforce policies – L4.Fiasco: current stable version (Fiasco) • But what is inevitable? – L4.X0: experimental, legacy (Fiasco, Hazelnut) – Abstractions – L4.X2, L4.V4: experimental / stable new API • Threads (Pistachio, Fiasco) • Address spaces (tasks) – L4.sec: experimental capability support – Mechanisms (Fiasco) • Communication – L4.v2: original Liedtke-compatible ABI version, • Mapping now deprecated • Scheduling TU Dresden, 2007-10-09 MOS - Introduction Slide 19 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 20 von 36 L4 – Recursive Address spaces L4 - Threads Address Space • Thread ::= Unit of Execution Application Application Application • Unique Thread ID • Properties managed by L4: – Instruction Pointer (EIP) Threads – Stack (ESP) Code Pager 3 – Registers • User-level applications need to Data – allocate stack memory Pager 1 Pager 2 – provide memory for application binary – find entry point Stack – ... Physical Memory Stack • 1 Address space can contain up to 128 threads TU Dresden, 2007-10-09 MOS - Introduction Slide 21 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 22 von 36 L4 - Communication L4 IPC – Message types • Synchronous inter-process communication • short (register-only) IPC (IPC) between threads • fast – no memory access – agreement between partners necessary Thread A Thread B – timeouts send(…) receive(…) – no in-kernel buffering – efficient implementation necessary • IPC flavors: – send – receive_from (closed wait) – receive (open wait) EBX EBX – call (send and receive_from) EDX EDX – reply and wait (send and receive) TU Dresden, 2007-10-09 MOS - Introduction Slide 23 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 24 von 36 L4 IPC – Message types L4 IPC – Message types • Direct long IPC – more than 2 words at a time • Indirect Long IPC (String IPC) • Words are directly copied: • Words in message buffer point to external Thread A Thread B memory areas that are copied send(msg,…) receive(msg, …) Thread A Thread B send(msg,…) receive(msg, …) copy copy TU Dresden, 2007-10-09 MOS - Introduction Slide 25 von 36 TU Dresden, 2007-10-09 MOS - Introduction Slide 26 von 36 L4 - Mappings L4 – Hardware Interrupts • Threads can map pages from their address • Special Thread ID to receive HW interrupts space to other address spaces. from the kernel • This is achieved by adding a Flexpage • Exaclty one thread can listen to exactly one descriptor to the IPC message buffer. interrupt – multiplexing in userspace • Flexpages describe mapping necessary. – location and size of memory area • I/O Memory and I/O ports are manages using – receiver's rights (read-only, read-writable) flexpages. – type (memory, IO, communication capability) ipc_recv IRQ (irq_id, ...)