The Hierarchical Microkernel: Existing Approaches A Flexible and - - PowerPoint PPT Presentation

the hierarchical microkernel
SMART_READER_LITE
LIVE PREVIEW

The Hierarchical Microkernel: Existing Approaches A Flexible and - - PowerPoint PPT Presentation

HM OS Architecture Stefan Winter Problem Statement The Hierarchical Microkernel: Existing Approaches A Flexible and Robust OS Architecture Proposed Solution Summary Stefan Winter, Martin Tsarev, Neeraj Suri DEEDS Group, TU Darmstadt


slide-1
SLIDE 1

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

The Hierarchical Microkernel: A Flexible and Robust OS Architecture

Stefan Winter, Martin Tsarev, Neeraj Suri DEEDS Group, TU Darmstadt moduli-os@deeds.informatik.tu-darmstadt.de

8th November 2013

1 / 13

slide-2
SLIDE 2

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

My PhD research focus

Robustness

Correct operation despite invalid inputs stressful environmental conditions

2 / 13

slide-3
SLIDE 3

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

My PhD research focus

Less critical component More critical component

Robustness

Correct operation despite invalid inputs stressful environmental conditions

2 / 13

slide-4
SLIDE 4

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

How (most) software systems evolve

Composition

static linking dynamic linking

Problems

static: system down time

  • dynamic. . . ?

3 / 13

slide-5
SLIDE 5

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

How (most) software systems evolve

Composition

static linking dynamic linking

Problems

static: system down time

  • dynamic. . . ?

3 / 13

slide-6
SLIDE 6

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Monolithic compositions do (not) support robust evolution

OS kernel DD1 DD2 Hardware App Ext

4 / 13

slide-7
SLIDE 7

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Monolithic compositions do (not) support robust evolution

OS kernel DD1 DD2 Hardware App Ext

4 / 13

slide-8
SLIDE 8

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Monolithic compositions do (not) support robust evolution

OS kernel DD1 DD2 Hardware App Ext

4 / 13

slide-9
SLIDE 9

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Monolithic compositions do (not) support robust evolution

OS kernel DD1 DD2 Hardware App Ext

4 / 13

slide-10
SLIDE 10

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Extensions are difficult to get right

c Palix et al., Faults in Linux: ten years later, ASPLOS’11

5 / 13

slide-11
SLIDE 11

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Problems with software evolution

1 components of different criticality 2 components of different origin (COTS/SOUP) 3 uniform privilege 4 complex and volatile interfaces evolve independently 6 / 13

slide-12
SLIDE 12

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Solution 1: Sandboxing

Nooks: Linux driver sandboxing1 Microdrivers2: performance-critical code in the kernel BGI: Byte-Granularity Isolation3 (L)XFI: Windows/Linux in-kernel fault isolation4,5

Sandboxing issues

available? working? co-evolution with OS required

1Swift et al.: Improving the Reliability of Commodity Operating Systems, SOSP’03 2Ganapathy et al.: The design and implementation of microdrivers, ASPLOS’08 3Castro et al.: Fast Byte-Granularity Software Fault Isolation, SOSP’09 4Erlingsson et al.: XFI: software guards for system address spaces, OSDI’06 5Mao et al.: Software fault isolation with API integrity and multi-principal modules, SOSP’11 7 / 13

slide-13
SLIDE 13

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Solution 1: Sandboxing

Nooks: Linux driver sandboxing1 Microdrivers2: performance-critical code in the kernel BGI: Byte-Granularity Isolation3 (L)XFI: Windows/Linux in-kernel fault isolation4,5

Sandboxing issues

available? working? co-evolution with OS required

1Swift et al.: Improving the Reliability of Commodity Operating Systems, SOSP’03 2Ganapathy et al.: The design and implementation of microdrivers, ASPLOS’08 3Castro et al.: Fast Byte-Granularity Software Fault Isolation, SOSP’09 4Erlingsson et al.: XFI: software guards for system address spaces, OSDI’06 5Mao et al.: Software fault isolation with API integrity and multi-principal modules, SOSP’11 7 / 13

slide-14
SLIDE 14

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Solution 2: Isolation by design

Virtual Machines6: high redundancy Singularity7: type safety, limited runtime protection Microkernels8

6LeVasseur et al.: Unmodified device driver reuse and improved system dependability via virtual machines, OSDI’04 7Hunt et al.: Broad New OS Research: Challenges and Opportunities, HotOS’05 8Herder et al.: Fault isolation for device drivers, DSN’09 8 / 13

slide-15
SLIDE 15

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Proposed solution: “Hierarchical” µ-kernel

Two core concepts:

1 broadcast IPC 2 recursive system (de)composition 9 / 13

slide-16
SLIDE 16

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Broadcast communication and scalability

Microkernel (HAL) Driver Shadow Driver9 Shared Library Random Application Communication Bus

HM building blocks

Modules: small isolated executable entities Buses: broadcast message-passing for inter-module communication (in software)

9Swift et al.: Recovering device drivers, ACM TOCS 24 4/2006 10 / 13

slide-17
SLIDE 17

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Broadcast communication and scalability

Microkernel (HAL) Driver Shadow Driver9 Shared Library Random Application Communication Bus

Pros

safe evolution no interposition mechanisms required for reconfiguration unbounded scalability?

Cons

Congestion Bus as SPOF Confidentiality? Availability?

9Swift et al.: Recovering device drivers, ACM TOCS 24 4/2006 10 / 13

slide-18
SLIDE 18

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Mitigating the downsides of broadcast: Hierarchical (de)composition

Microkernel (HAL) File System Drivers Application Group Communication Bus Application 1 Application 2 Driver Shadow Driver Library Untrusted Extension

11 / 13

slide-19
SLIDE 19

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Hierarchical (de)composition

Hierarchy

Parent/Child relation across modules and buses: Manage children

multiplex resources provided by lower layer provide “system calls”

→ Trust parents

Pros

Broadcast scope restriction Management load distribution Distance from kernel reflects degree of distrust

Cons

Communication

  • verheads (routing)

Hierarchy emulation on binary privilege architectures

12 / 13

slide-20
SLIDE 20

HM OS Architecture Stefan Winter Problem Statement Existing Approaches Proposed Solution Summary

Wrap-up

Problems

1 components of different criticality 2 components of different origin (COTS/SOUP) 3 uniform privilege 4 complex and volatile interfaces evolve independently

Proposal

localized broadcast communication fair management overhead distribution more fine-grained trust/overhead trade-off

13 / 13