Microkernel-based Operating Systems - Introduction

Transcription

1 Faculty of Computer Science Institute for System Architecture, Operating Systems Group Microkernel-based Operating Systems - Introduction Björn Döbel Dresden, Oct 14 th 2008

2 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, MOS - Introduction Slide 2 von 37

3 Administration - Lecture Lecture every Tuesday, 1:00 PM, INF/E08 Lecturers: Carsten Weinhold, Michael Roitzsch, Stefan Kalkowski, Björn Döbel Slides: -> Teaching -> Microkernel-based Operating Systems Subscribe to our mailing list: This lecture is not: Microkernel construction (in summer term) TU Dresden, MOS - Introduction Slide 3 von 37

4 Administration - Exercises Exercises bi-weekly, Tuesday, 2:50 PM, INF/E08 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: next week, computer pool You'll need a quota raise. TU Dresden, MOS - Introduction Slide 4 von 37

5 Complex lab Complex lab in parallel to lecture 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 Tuesday, Oct 14 th TU Dresden, MOS - Introduction Slide 5 von 37

6 Monolithic kernels - Linux User mode Application Application Application Application Kernel mode System-Call Interface Linux Kernel File Systems VFS File System Impl. Device Drivers Networking Sockets Protocols Processes Scheduling IPC Memory Management Page allocation Address spaces Swapping Hardware Access Hardware CPU, Memory, PCI, Devices TU Dresden, MOS - Introduction Slide 6 von 37

7 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, MOS - Introduction Slide 7 von 37

8 The microkernel vision User mode Application Application Application Application File Systems VFS File System Impl. Device Drivers Networking Sockets Protocols Memory Management Page allocation Swapping Kernel mode Microkernel System-Call Interface Hardware Access Address Spaces Threads Scheduling IPC Hardware CPU, Memory, PCI, Devices TU Dresden, MOS - Introduction Slide 8 von 37

9 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 Safer crashing component does not (necessarily...) crash the whole system TU Dresden, MOS - Introduction Slide 9 von 37

10 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, MOS - Introduction Slide 10 von 37

11 Examples QNX kernel only contains IPC Scheduling IRQ redirection File system Device manager QNX µkernel Process Manager Network stack LynxOS separation kernel combine secure and real-time components App A App B System Services Partitions App A System Services LynxOS Separation Kernel (Microkernel) Hardware Security Policy System Services TU Dresden, MOS - Introduction Slide 11 von 37

12 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, MOS - Introduction Slide 12 von 37

13 Mac OS X App Environments BSD Cocoa Carbon Quartz Window Manager Application services Quick Time AWT, Swing JRE Core services JVM User space Mach BSD Drivers, I/O kit Kernel Hardware TU Dresden, MOS - Introduction Slide 13 von 37

14 IBM Workplace OS Main goals: multiple OS personalities run on multiple HW architectures Win Apps Unix Apps OS/2 Apps Windows Personality Unix Personality OS/2 Personality Network Processes Power... Files OS base services Mach microkernel ARM PPC x86 MIPS Alpha TU Dresden, MOS - Introduction Slide 14 von 37

15 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, MOS - Introduction Slide 15 von 37

16 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, MOS - Introduction Slide 16 von 37

17 Proven advantages Subsystem protection / isolation Code size Fiasco kernel: ~ 15,000 LoC Minimal application: (boot loader + hello world ): ~ 6,000 LoC Linux kernel (2.6.24, x86 architecture): ~ 1.6 million LoC (+drivers: ~ 2.8 million LoC) (generated using David A. Wheeler's 'SLOCCount') Customizable Tailored memory management / scheduling / algorithms Adaptable to embedded / real-time / secure / systems TU Dresden, MOS - Introduction Slide 17 von 37

18 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, MOS - Introduction Slide 18 von 37

19 Who's out there? FU Amsterdam (Tanenbaum) MS Research Johns Hopkins University The L4 Microkernel Family Originally developed by Jochen Liedtke at IBM and GMD 2 nd generation microkernel Several kernel ABI versions TU Dresden, MOS - Introduction Slide 19 von 37

20 The L4 family a timeline N1 N2 SeL4 Univ. of New South Wales / NICTA / Open Kernel Labs NICTA:: Pistachio-embedded OKL4v2 OKL4 L2, L3 L4/x86 v2 x0 x2/v4 ABI Specification Implementation Univ. of Karlsruhe L4Ka::Hazelnut L4Ka::Pistachio Fiasco/L4v2 Fiasco Fiasco.XY? TU Dresden L4.Sec Fiasco/L4.Fiasco fiasco_dev TU Dresden, MOS - Introduction Slide 20 von 37

21 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, MOS - Introduction Slide 21 von 37

22 L4 - Threads Thread ::= Unit of Execution Unique Thread ID Properties managed by L4 kernel: Instruction Pointer (EIP) Stack (ESP) Registers User-level applications need to allocate stack memory provide memory for application binary find entry point... 1 addr. space contains up to 128 threads Address Space Threads Code Data Stack Stack TU Dresden, MOS - Introduction Slide 22 von 37

23 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, MOS - Introduction Slide 23 von 37

24 L4 IPC Message types short (register-only) IPC fast no memory access Thread A Thread B send( ) receive( ) EBX EDX EBX EDX TU Dresden, MOS - Introduction Slide 24 von 37

25 L4 IPC Message types Direct long IPC more than 2 words at a time Words are directly copied: Thread A Thread B send(msg, ) receive(msg, ) copy TU Dresden, MOS - Introduction Slide 25 von 37

26 L4 IPC Message types Indirect Long IPC (String IPC) Words in message buffer point to external memory areas that are copied Thread A Thread B send(msg, ) receive(msg, ) copy TU Dresden, MOS - Introduction Slide 26 von 37

27 L4 - Mappings Threads can map pages from their address space to other address spaces. This is achieved by adding a Flexpage descriptor to the IPC message buffer. Flexpages describe mapping location and size of memory area receiver's rights (read-only, read-writable) type (memory, IO, communication capability) More general: flexpages as fundamental resource abstraction TU Dresden, MOS - Introduction Slide 27 von 37

28 L4 Recursive address spaces RAM Physical Memory Device Memory TU Dresden, MOS - Introduction Slide 28 von 37

29 L4 Hardware Interrupts Special Thread ID to receive HW interrupts from the kernel Exaclty one thread can listen to exactly one interrupt multiplexing in userspace necessary. I/O Memory and I/O ports are manages using flexpages. IRQ Kernel ipc_recv (irq_id,...) User-space device driver TU Dresden, MOS - Introduction Slide 29 von 37

30 System Calls in L4.Fiasco Address spaces l4_task_new create/delete tasks Threads l4_thread_ex_regs create/modify threads l4_thread_schedule setup scheduling parameters l4_thread_switch switch to another thread IPC l4_ipc perform IPC l4_fpage_unmap revoke flexpage mapping l4_nchief find next chief TU Dresden, MOS - Introduction Slide 30 von 37

31 Linux on L4 Application Application Application Application L4 Task L4 Task L4 Task L4 Task System-Call Interface arch-dep Linux Kernel File Systems VFS File System Impl. Device Drivers Networking Sockets Protocols Processes Scheduling IPC Memory Management Page allocation Address spaces Swapping Archindep. Hardware Access arch-dep L4 Task User mode L4 Environment Kernel mode Fiasco Hardware TU Dresden, MOS - Introduction Slide 31 von 37

32 The Dresden Real-Time Operating System Apps Time RT Apps service L4Linux Network SCSI Display driver driver driver User Mode Privileged Mode Non-RT World RT World Resource Management Layer (L4Env) L4.Fiasco microkernel TU Dresden, MOS - Introduction Slide 32 von 37

33 Virtual machines Isolate not only processes, but also complete Operating Systems (compartments) Server consolidation Apps Apps Apps L4Linux L4Linux L4Linux User Mode Privileged Mode Virtualization Layer (L4Env) L4.Fiasco microkernel TU Dresden, MOS - Introduction Slide 33 von 37

34 Bastei Disadvantages of existing systems (microkernels as well as monoliths): global naming resource management and revokation difficult hard to get security policies right Bastei := C++-based OS framework developed here in Dresden recursive system design capabilities stacked security policies Bastei::Core Parent 1 Parent 2 Child Child Child Child Child TU Dresden, MOS - Introduction Slide 34 von 37

35 Design alternatives Hardware isolation x86 privilege rings, privileged instructions Software isolation N. Wirth's Oberon language and OS since 1980s Singularity from MS Research written in a dialect of C# (since 2000s) Exokernels build OS interface into a library and link it to single applications (library OS) TU Dresden, MOS - Introduction Slide 35 von 37

36 Lecture outline Basic mechanisms and concepts Memory management Tasks, Threads, Synchronization Communication Building real systems What are resources and how to manage them? How to build a secure system? How to build a real-time system? How to reuse existing code (Linux, standard system libraries, device drivers)? How to improve robustness and safety? TU Dresden, MOS - Introduction Slide 36 von 37

37 Outlook Next lecture: Tasks, Threads and Synchronization on Oct 21 st Next exercise: Oct 21 st Building and booting an L4 system TU Dresden, MOS - Introduction Slide 37 von 37