the l4 microkernel - artist-embedded.org · hermann h rtig l4 microkernel micro 5 l4 microkernel...
Post on 09-Sep-2018
229 Views
Preview:
TRANSCRIPT
����
http://www.artist-embedded.org/
ARTIST Summer School in Europe 2010
Autrans (near Grenoble), France
September 5-10, 2010
The L4 Microkernel
Invited Speaker: Prof. Hermann Härtig
Technische Universität Dresden
����
http://www.artist-embedded.org/
L4
Hermann Härtig L4 Microkernel
COTS - SW
Firefox Flash
Linux!Kernel
X11
Keyboard
Applet
3
Hermann Härtig L4 Microkernel
MICRO
4
L4 Microkernel
Window Server
Framebuffer!Driver
Disk Driver
Network Driver
File System
IP Stack
Native Microkernel
App
Native Microkernel
App
Hermann Härtig L4 Microkernel
MICRO
5
L4 Microkernel
Virtualization!Container for
Legacy OSWindow Server
Framebuffer!Driver
Disk Driver
Network Driver
File System
IP Stack
Native Microkernel
App
Native Microkernel
App
Hermann Härtig L4 Microkernel
OUTLINE
■ Using a small kernel – Hermann Härtig
■ Motivation, Cost & Benefit
■ Case studies
■ A short history of L4
■ L4 Kernel interface
■ Capability system design – Michael Roitzsch
■ Mobile use cases – Adam Lackorzynski
6
Department of Computer Science Institute of System Architecture, Operating Systems Group
HERMANN HÄRTIG
USING A SMALL KERNEL
Hermann Härtig L4 Microkernel
WHY MICRO
8
L4 Microkernel
Virtualization!Container for
Legacy OSWindow Server
Framebuffer!Driver
Disk Driver
Network Driver
File System
IP Stack
Native Microkernel
App
Native Microkernel
App
Hermann Härtig L4 Microkernel
COST & BENEFIT
■ Performance
■ (Failure) Isolation
■ Openness
■ Small (Minimal) Trusted Computing Base
9
Hermann Härtig L4 Microkernel
BENEFITS
■ Flexibility?SW engineering ./. microkernels
■ Difficulty to build?can be harder to build
10
Hermann Härtig L4 Microkernel
ISOLATION■ Separate address spaces for components
■ Message passing interfaces
■ Communication controlled by capabilities
■ Immediate: I/O Drivers tamed
■ Base for fault containment
■ fault recovery?11
Hermann Härtig L4 Microkernel
ALTERNATIVEVirtual machines
■ provide separate machines
■ requires
■ emulation of physical HW interface
■ an operating system in each VM
■ large!grained components
more later12
Hermann Härtig L4 Microkernel
ALTERNATIVELanguages with component!support
■ Use one language or language family
■ Fine!grained components(modules, objects, …)
■ Compiler and runtime enforce isolation
■ Closed systems
■ Examples: Burroughs 7700, B extended Algol, Espol, Concurrent Pascal, Modula, Oberon, various Java systems
13
Hermann Härtig L4 Microkernel
OPENNESS
Microkernels
■ Minimal kernel and hardwareenforce separation
■ Only kernel runs in CPU privileged mode
■ Components are user!level processes
■ No restrictions on component software
■ Reuse of legacy software
14
Hermann Härtig L4 Microkernel
MINIMAL TCB
„A small amount of software and hardware that security depends on and that we distinguish from a much larger amount that can misbehave without affecting security.“
— Lampson et al.
15
Trusted Computing Base
Hermann Härtig L4 Microkernel
MINIMAL TCB
„A small amount of software and hardware that * depends on and that we distinguish from a much larger amount that can misbehave without affecting * .“
In this lecture:* : security, real!time, fault tolerance, ...TCB is application specific
16
Trusted Computing Base
Hermann Härtig L4 Microkernel
MINIMAL TCB■ General Approach:
■ Divide system into uncritical and (minimal) critical parts
■ Include minimal set of components into TCB
■ offload uncritical parts, e.g. into legacy SW
■ Split critical part into isolated components
■ Benefit:
■ small application!specific TCB
17
Hermann Härtig L4 Microkernel
CASE STUDIES
18
Hermann Härtig L4 Microkernel
L4LINUX
19
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
Hermann Härtig L4 Microkernel
(Härtig, Hohmuth, Liedtke, Schönberg, Wolter: The Performance of !-Kernel based Systems, SOSP 1997)"
jobs
per
min
ute
simulated load L4
L4Linux
Time-Sharing
Applications
COST !1997
Hermann Härtig L4 Microkernel
L4
L4Linux
Time-Sharing
Applications
COST !1997
Hermann Härtig L4 Microkernel
L4LINUX
22
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
L4Linux Server
X11
App App
Hermann Härtig L4 Microkernel
L4RE
23
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
L4Linux Server
X11
App App
moe ned io rtc mag
Resource Management and
Virtualization Support Layer
Hermann Härtig L4 Microkernel
L4RE
24
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
L4Symbian Server
App App
moe ned io rtc mag
Hermann Härtig L4 Microkernel
L4LINUX
25
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
L4Linux Server
X11
App App
Hermann Härtig L4 Microkernel
L4RE
26
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
L4Linux Server
X11
App App
moe ned io rtc mag
Resource Management and
Virtualization Support Layer
Hermann Härtig L4 Microkernel
L4RE
27
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
L4Symbian Server
App App
moe ned io rtc mag
Hermann Härtig L4 Microkernel
NATIVE APPS
28
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
moe ned io rtc mag
Security!Sensitive Application
Hermann Härtig L4 Microkernel
HYBRID APPS
29
L4 Microkernel Fiasco.OC
L4Linux Server
X11
Helper App
moe ned io rtc mag
Secure Application Core
Security!Sensitve Application
Hermann Härtig L4 Microkernel
CASE STUDY
Micro!SINA VPN Box
■ security goals:
■ connect sets of trusted machines
■ ensure confidentiality and integrity
■ non goal:
■ availability
30
Hermann Härtig L4 Microkernel
USE CASES
31
L4 Microkernel Fiasco.OC
L4Linux Server L4Linux Server
moe ned io rtc mag
IP Viaduct
eth0 eth1
Hermann Härtig L4 Microkernel
USE CASES
32
L4 Microkernel Fiasco.OC
DDE DDE
moe ned io rtc mag
IP Viaducteth0 eth1
Hermann Härtig L4 Microkernel
HYBRID APPS
33
L4 Microkernel Fiasco.OC
L4Linux Server
X11
Slide Loader
moe ned io rtc mag
Presenter
Presentation Application
Hermann Härtig L4 Microkernel
HYBRID APPS
34
L4 Microkernel Fiasco.OC
L4Linux Server
X11
E!Mail Client
moe ned io rtc mag
E!Mail Signing
Hermann Härtig L4 Microkernel
HYBRID APPS
35
L4 Microkernel Fiasco.OC
L4Linux Server
X11
Address Book
moe ned io rtc mag
Dialer with Filter forPremium!rate Numbers
ROBIN Demo Scenario
Hermann Härtig L4 Microkernel
HYBRID APPS
36
L4 Microkernel Fiasco.OC
L4Linux Server
X11
Browser
moe ned io rtc mag
Secure Transactions forHome!Banking
Nizza Demo Scenario
Hermann Härtig L4 Microkernel
NUMBERS
37
Reducing TCB Complexity for Security!Sensitive Applications: Three Case Studies Lenin Singaravelu, Calton Pu, Hermann Härtig, Christian Helmuth, EuroSys 2006
ScenarioScenarioOriginalOriginal AppCoreAppCore Reduc!
tion FactorkLOC kMCC kLOC kMCC
Reduc!tion
Factor
e!commerceBrowser
VPN GatewayFreeS/WAN
Email signerThunderbird
TCBLinux + X11
978 151 10 15 100"
155 25 74 10 2.1"
250 45 54 11 4.6"
1485 238 100 14 14"
Hermann Härtig L4 Microkernel
REAL-TIME
38
L4 Microkernel Fiasco.OC
L4Linux Server
X11
App App
moe ned io rtc mag
Real!Time Application
Hermann Härtig L4 Microkernel
REAL-TIME
39
L4 Microkernel Fiasco.OC
L4Linux Server
Legacy App
moe ned io rtc mag
Real!Time App
DOpE
Hybrid App
RT!Disk
RT!File RT!Net
RT!NIC
Stu
bs
Hermann Härtig L4 Microkernel
ORTHOGONAL
Light!Weight Microkernels■ Componentization of operating system■ Split applications■ Critical part on microkernel■ Uncritical on commodity OS
■ Small Trusted Computing Bases40
Microkernel Virtual Machine
Isolation Rehosting
Hermann Härtig L4 Microkernel
ORTHOGONAL
Virtual Machines
■ Provide virtual hardware interface
■ Reuse of COTS operating systems and applications with no modification
■ At the price of complexity41
Microkernel Virtual Machine
Isolation Rehosting
Hermann Härtig L4 Microkernel
NOVA
42
State of the Art: Monolithic Hypervisors
Udo Steinberg NOVA 4
Monolithic hypervisor is single point of failure
guest mode
host mode
Monolithic Hypervisor
x86 Virtualization
VM VM VM
Device Drivers
ManagementStorage
Network> 100,000 lines of code
Hermann Härtig L4 Microkernel
NOVA
43
NOVA OS Virtualization Architecture
Udo Steinberg NOVA 7
guest mode
host modeMicrohypervisor
Partition Manager
VMM
Applications Device Drivers!"#$
%#$&#'
VM
VMM VMM
VM VM
9,000 LOC
20,000 LOC
7,000 LOC
Hermann Härtig L4 Microkernel
SHORT HISTORY• Eumel, L3, BirliX
• first version of L4
• L4Linux, the first major application
• Fiasco, the first HLL implementation
• PikeOS: first commercial derivative
• real!time systems based on Fiasco
• Pistachio (Uni Karlsruhe)
44
1995
1997
1998
Hermann Härtig L4 Microkernel
SHORT HISTORY• First commercial usage (Fiasco on a
DRM product)
• Qualcomm adopts L4 kernel from NICTA (Pistachio derivative)
• Full formal verification of implementation in Haskell (NICTA)
• Fiasco.OC, L4Re
• NOVA
45
2009
2009
2009
2005
2000
Hermann Härtig L4 Microkernel
L4 KERNEL ABSTRACTIONS
46
Hermann Härtig L4 Microkernel
ABSTRACTIONS
■ Task (Address space: memory & capabilities)
■ Thread
■ Communication (IPC)
47
Hermann Härtig L4 Microkernel
MAIN MEMORY
■ Management of Physical Memory at user"level?
■ only kernel can access page tables?
48
Hermann Härtig L4 Microkernel
MAIN MEMORY
49
Task B
Task A
Task C Task D
Page Fault transformed into
message to handler
Hermann Härtig L4 Microkernel
MAIN MEMORY
50
Task B
Task A
Task C Task D
Handler returns message with
PTE as payload,kernel adds to address space
Hermann Härtig L4 Microkernel
MAIN MEMORY
51
Task B
Task A
Task C Task D
Hermann Härtig L4 Microkernel
MAIN MEMORY
52
Task B
Task A
Task C Task D
revoke:kernel maintains data structure for
revoking!
! !
Hermann Härtig L4 Microkernel
USES OF IPC
■ data
■ exceptions
■ interrupts
■ memory references (page fault handling)
■ capabilities
53
Hermann Härtig L4 Microkernel
NEXT …
■ Using a small kernel – Hermann Härtig
■ Capability system design – Michael Roitzsch
■ Mobile use cases – Adam Lackorzynski
54
Department of Computer Science Institute of System Architecture, Operating Systems Group
MICHAEL ROITZSCH
DESIGN OF A CAPABILITY SYSTEM
Michael Roitzsch Design of a Capability System
SYSTEM DESIGN
2
Kernel
Services
Applications
Michael Roitzsch Design of a Capability System
DESIGN GOALS
3
■ application!centric interfaces
■ object!based design
■ easy setup and destruction of subsystems
■ object invocation by message passing
■ uniform security model
■ all services virtualizable
■ flexible and efficient support for multicore
Michael Roitzsch Design of a Capability System
EXAMPLE
4
Service
Manager
Worker A Worker B
Michael Roitzsch Design of a Capability System
GOOGLE CHROME
5
■ separate processes
■ chrome parent
■ sandboxes for tabs
■ implementation on Linux: glorious mix of chroot(), clone() and setuid()
■ there must be a better way…
Michael Roitzsch Design of a Capability System
TWO WORLDS
6
POSIX POLA
operations allowed by default
nothing allowed by default
some limited restrictions apply
every right must be granted
ambient authority explicit authority
Michael Roitzsch Design of a Capability System
L4RE
7
L4Re — the L4 Runtime Environmentset of libraries and system services on
top of the Fiasco.OC microkernel
Microkernel L4Re
Michael Roitzsch Design of a Capability System
CAPABILITIES
8
■ Fiasco.OC and L4Re form anobject!capability system
■ actors in the system are objects
■ objects have local state and behavior
■ capabilities are references to objects
■ object interaction requires a capability
■ capabilities cannot be forged
Michael Roitzsch Design of a Capability System
CAPABILITIES
9
Fiasco.OC
Task A
A B C D E
Task BC
apab
ility
Tab
le 1
2
3
4
5 Cap
abili
ty Ta
ble1
2
3
4
5
Michael Roitzsch Design of a Capability System
HOW TO USE?
10
■ invocation of any object requires a capability to that object
■ no global names
■ no sophisticated rights representation beyond capability ownership
■ just four rights bits on objects
■ C++ language integration
■ capabilities passed as message payload
Michael Roitzsch Design of a Capability System
CAP TRANSFER
11
A
Task A Task B
Michael Roitzsch Design of a Capability System
CAP TRANSFER
11
A
Task A Task B
1 2 3 4 5 1 2 3 4 5
Michael Roitzsch Design of a Capability System
EXAMPLE
12
Manager
Service
Worker A Worker B
Michael Roitzsch Design of a Capability System
How do you send an answer to a client?
■ Always include a backward capability in every request?
■ Establish backward capability once and cache?
■ call!return!semantics as the standard case
■ implicit reply capability
■ use!once, cannot be passed on
ANSWERING
13
Michael Roitzsch Design of a Capability System
EXAMPLE
14
Manager
Worker A Worker B
mag
Michael Roitzsch Design of a Capability System
mag
MAG■ factory for new
framebuffer sessions
■ session object
■ backing store memory
■ view: visible rectangle on the backing store
■ metadata, refresh method
■ How does it appear on the screen?
15
Factory S S
Manager
Michael Roitzsch Design of a Capability System
mag
MAG■ hardware framebuffer is
memory with side effect
■ all memory is initially mapped to the roottask
■ framebuffer driver
■ find framebuffer memory
■ wrap in FB!interface
■ same interface as mag’s
16
Factory S S
Memory
moe
fb!drv
Michael Roitzsch Design of a Capability System
INTERFACES■ L4Re uses one interface per resource
■ low!level system resources are managed by the kernel
■ CPU, memory, IRQ
■ minimal policy
■ user!level servers can reimplement and augment interfaces
■ virtualizable interfaces
17
Michael Roitzsch Design of a Capability System
EXAMPLE
18
Manager
Service
Worker B
mag?
Michael Roitzsch Design of a Capability System
SUBSYSTEMSSubsystem Life
■ subsystems are opaque
■ parents can restrict the resources
■ parents cannot restrict their sub!structure
Subsystem Death
■ How to deallocate resources in servers?
■ notify all servers used by the subsystem?
■ garbage collection19
Michael Roitzsch Design of a Capability System
CONCLUSION! coherent per!resource interfaces "
! all services provided as objects "
! garbage collection for server resources "
! invocation is the only system call "
! object!capability system "
! all interfaces can be interposed "
! see next talk "
20
Department of Computer Science Institute of System Architecture, Operating Systems Group
ADAM LACKORZYŃSKI
MOBILE USE CASES
Adam Lackorzynski Mobile Use Cases 2
OUTLINE
■ ICT!eMuCo project
■ Multi!Cores and Load Balancing
■ Virtualization
Adam Lackorzynski Mobile Use Cases 3
ICT-EMUCO■ Embedded Multicore
Computing
■ FP7 Project, STREP
■ Feb 2008 – Jan 2010
■ Partners:
■ ARM, Infineon, Ruhr!Uni Bochum, IBM, Uni of Timisoara, Uni York, TU!Dresden
Adam Lackorzynski Mobile Use Cases 4
ARCHITECTURE
■ Microkernel based system
■ ARM11MPCore
■ 4 cores
■ Modem Stack
■ App!OS
Adam Lackorzynski Mobile Use Cases 5
THE EMUCO OS■ Isolation
■ Secure communication
■ Timing properties
■ Multi!core capable
■ Power Management
■ Embedded systems
■ Flexible & usable
Fiasco.OC Microkernel
Hardware Platform
L4Re Runtime Environment
ProtocolStack
Adam Lackorzynski Mobile Use Cases 6
OUTLINE
■ ICT!eMuCo project
■ Multi!Cores and Load Balancing
■ Virtualization
Adam Lackorzynski Mobile Use Cases 7
MULTI-CORES■ Shared memory multi!processor systems
■ Model:
■ Cross CPU tasks
■ Cross CPU notifications
■ Cross CPU IPC
■ Shared memory
■ Local scheduling
■ Fixed!prio, round!robin scheduler on each core
Adam Lackorzynski Mobile Use Cases 8
DISTRIBUTIONHow to Distribute Work?
■ Kernel provides migration mechanism
■ No automatic migration, decision is policy
CPU1 CPU2 CPU3 CPU4
?App1
App2App3
Adam Lackorzynski Mobile Use Cases 9
L4::SCHEDULER■ L4::Scheduler interface
■ Run/Migrate a thread with parameters
■ Priority, CPU set, budget, ...
■ scheduler.run_thread(thread, sched_param);
■ Kernel implementation
■ Singleton, has all resources (all CPUs, all CPU time)
■ Chooses one CPU from CPU set, fixed
Adam Lackorzynski Mobile Use Cases 10
LOAD BALANCING■ Load balancer component
■ Implements L4::Scheduler interface
■ Hides platform details from application
■ Implements policy
CPU1 CPU2 CPU3 CPU4
?App1
App2App3
Load Balancer
Adam Lackorzynski Mobile Use Cases 11
LOAD BALANCER
■ Implements balancing strategy
■ Application specific scheduler instances
■ Enforces scheduling policies
■ Combines client policies
Fiasco.OC
CPU
LB
CPU CPU CPU
3 CPUs 2 CPUs
Scheduler
Scheduler SchedulerPolicy
ProtocolStack
Adam Lackorzynski Mobile Use Cases 12
USE CASES■ Multi!threaded program
■ Distribute and balance
■ Sophisticated real!time application
■ No migration by load balancer
■ Threads always on the same CPU (cache locality)
■ Threads always on different CPUs (no interference)
■ Virtual machine
Adam Lackorzynski Mobile Use Cases 13
OUTLINE
■ ICT!eMuCo project
■ Multi!Cores and Load Balancing
■ Virtualization
Adam Lackorzynski Mobile Use Cases 14
VIRTUALIZATION■ Application side
■ Standard OS → Standard applications
■ Integration in the system
■ Resource anddevice usage
■ Isolation of thevirtual machine
■ No disturbance ofother programs
Fiasco.OC Microkernel
Hardware Platform
L4Re Runtime Environment
ProtocolStack
Adam Lackorzynski Mobile Use Cases 15
EMUCO PLATFORM
■ ARM architecture
■ Available CPU features: MMU
■ Paravirtualization – L4Linux
■ TECOM!FP7: TrustZone for Virtualization
Adam Lackorzynski Mobile Use Cases 16
L4LINUX■ Adapted Linux kernel
■ runs on Fiasco.OC & L4Re■ „Normal“ program, runs Linux kernel code
in user mode, including device drivers
■ Binary compatible for applications
■ Address space for kernel and each program
■ Programs isolated from each other■ Kernel isolated from programs
■ CPU, memory, devices
Adam Lackorzynski Mobile Use Cases 17
L4LINUX
L4Linux CPU Virtualization
■ Native execution
■ Exceptions reflected by microkernel
■ System calls
■ Page faults
■ Other exceptions
LinuxProgram
Linux Kernel
LinuxProgram
Microkernel
Fault handling
Adam Lackorzynski Mobile Use Cases 18
SMP
Multi!Processor Virtualization
■ Linux has multiple virtual CPUs (vCPU)
■ Shared memory between cores
■ Migration of application threads is done by the Linux kernel
■ Inter (v)CPU communication done with microkernel primitives
Adam Lackorzynski Mobile Use Cases 19
MEMORY
L4Linux Memory Virtualization
■ L4Re supplies Linux memory (virtual)
■ MMU managed by microkernel
■ Hooks in Linux page!table code use Fiasco memory!mapping functionality
Adam Lackorzynski Mobile Use Cases 20
DEVICES■ Virtual PCI bus and/or platform devices
■ Pass!through devices according to configuration
■ Stub drivers for L4Re services:
■ Framebuffer driver for windowing system
■ Input driver for keyboard/mouse events
■ Serial driver for basic input/output
■ Network drivers for virtual switch
Adam Lackorzynski Mobile Use Cases 21
PLATFORM■ Central IO service
■ Device discovery
■ Device enumeration
■ Per client device access
■ Virtual buses
■ Virtual interrupt controller
■ Device pass!through
Adam Lackorzynski Mobile Use Cases 22
VIRTUALIZATION
Faithful Virtualization
■ Unmodified guest OS
■ AMD SVM, Intel VT
■ 1500 LoC in Fiasco for SVM and VT support
■ Off!the!shelf VMM (e.g. QEmu on L4Linux)
Adam Lackorzynski Mobile Use Cases 23
WHAT ELSE?■ DDE, virtual network switch
■ Debugging: Valgrind
■ Checkpoint & Restart
■ ARM Virtualization
■ Run!time environment:libc, libstdc++, virtual!FS, pthread, communication framework, dynamic linking, scriptable startup with lua, ...
Adam Lackorzynski Mobile Use Cases 24
GO DOWNLOAD
http://L4Re.tudos.org
top related