CSC 660: Advanced Operating SystemsSlide #1 CSC 660: Advanced OS Microkernels

CSC 660: Advanced Operating Systems Slide #1

CSC 660: Advanced OS

Microkernels


Topics

1. What is a microkernel?

2. Mach and L4

3. Microkernel IPC

4. Microkernel Memory Management

5. Userspace Device Drivers

6. Nooks

7. Exokernels


What is a Microkernel?

Kernel with minimal featuresAddress spaces

Interprocess communication (IPC)

Scheduling

Other OS features run as user-space servers.Device drivers

Filesystem

Pager


Example Microkernel Architecture: MINIX 3


Microkernel Philosophy

A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e., permitting competing implementations would prevent the implementation of the systems' required functionality.

- Jochen Liedtke


Why use Microkernels?

Flexibility: can implement competing versions of key OS features, like filesystem or paging, for best performance with applications.

Safety: server malfunction restricted to that server (even drivers), not affecting rest of OS.

Modularity: fewer interdepencies and a smaller trusted computing base (TCB).


MachFirst generation microkernel.

Runs OS personality on top of microkernel.Core Abstractions

Tasks and Threads (kernel provides scheduling)Messages (instead of system calls)Memory Objects (allow userspace paging)


Mach Abstractions

Task: unit of execution consisting of an address space, ports, and threads.

Thread: basic unit of execution, shares address space, ports with other threads in task.

Port: communication channel used to send messages between tasks. Tasks must have correct port rights to send message to a task.

Message: basic unit of communication consisting of a typed set of data objects.

Memory Object: source of memory tasks can map into their address space; includes files and pipes.


Mach Threads and Messages• Threads have

multiple ports with different port rights.

• Send messages to ports instead of system calls.

• Task must have port rights to send message to port.


Mach Innovations

Message passing instead of system calls.Provide uniform interface to kernel.Can extend messages w/o recompiling kernel.

Userspace pagingDifferent tasks can use different pagers.

Multiprocessor / distributed OS.Ports can reside on system across network.Message passing works identically across network as on local system with NetMsgServer forwarding messages across network.


Mach Performance

System calls take 5-6X as long as UNIX.

Message PassingUses pointers, copy-on-write, and memory mapping to avoid unnecessary copies.

Port rights checks are expensive.

PagingPageout kernel thread determines system paging policy (which pages are paged out to disk.)

Pager servers handle actual writing.


L4 Microkernel

• Second generation microkernel.

• Faster– IPC is about 10X faster than Mach.– IPC security checks moved to user space

processes if needed.

• Smaller– L4 is 12KB. Compare to Mach 3 (330KB)– Memory management policy moved entirely to

userspace.


Microkernel IPC

Uniform way to handle kernel interactions.IPC Mechanisms

RegistersDirect copyMemory mapping

Most performance critical component.All interactions require 2 IPCs: request, response.Hand-off scheduling: CPU control may be transferred with message so recipient can respond without waiting to be rescheduled.


Handle Interrupts as IPC

Microkernel captures interrupts.Doesn’t handle.

Forwards interrupts to process as IPC.


Microkernel PagingMicrokernel forwards page fault to a pager server.

Kernel or server decides which pages need to be written to disk in low memory situations.

Pager server handles writing pages to disk.


Recursive Address Spaces (L4)

• Initial address space controlled by first process.– Controls all available memory.

– Other address spaces empty at boot.

• Other processes obtain memory pages from first or from their other processes that got pages from first.

• Why is memory manager flexibility useful?– Different applications: real-time, multimedia, disk cache.


Constructing Address Spaces

grant: remove page from your address space and give to another consenting process.

map: share page with another process.demap: remove page from all other processes that

received it directly or indirectly from demapper.


User Space Device Driver

How do they work?Receive interrupts as IPC.

I/O ports mapped to user address space.

AdvantagesDevice drivers have 3-7X bugs as kernel code.

User space driver bugs don’t reduce reliability.

User space driver bugs don’t reduce security.


User Space Device Driver

driver thread:

wait for (msg, sender)

if sender = my hw interrupt

read/write i/o ports

reset hw interrupt

else

pass

end


Nooks

Problem: Most kernel bugs in device drivers.Drivers written by less experienced programmers.

Drivers are tested less than core kernel code.

Solution: Lightweight protection domains.Kernel-mode env w/ restricted mem write access.

Isolate drivers from kernel code.


Nooks Goals

1. Isolation: Isolate kernel from extension failures.

2. Recovery: Automatic recovery after extension failure so applications can continue execution.

3. Backwards compatibility: Extensions should not have to be rewritten to use Nooks.


Nooks Architecture


Exokernels

Problem with traditional OSMost resource management decisions made once in a global fashion.

Exokernel solution• Let programmers make resource management

decisions when they write their applications.• Allows experimentation.• Allows for high performance for applications

that don’t fit OS assumptions, e.g. RDBMS.


What makes Exokernels Different?

• Separate security from abstraction.– ex: Protect disk blocks not files.

• Exokernel securely multiplexes hardware.• Move abstractions into userspace libraries

called library operating systems (libOSes.)• Exokernels vs Microkernels

– Microkernel concerned with implementing kernel in user space rather than kernel space.

– Exokernel concerned with separating security from abstraction to give applications control.


Applications on an Exokernel


Exokernel Tasks

1. Tracking ownership of resources.

2. Performing access control by guarding all usage or binding points.

3. Revoking access to resources.


Resource Revocation

Invisible revocation– Most OSes deallocate memory, CPU without

informating application.

Visible revocation– Exokernels visibly request that a resource be returned to

the kernel.

– Ex: Exokernel informs app that CPU is revoked at end of time slice, and app responds by saving required processor state.

– If application does not return resource, exokernel will take it from the application.


Exokernel Performance

Aegis/ExOS vs Ultrix performanceSystem calls 10X faster.

IPC 10-20+X faster.

Virtual memory1-5X faster.

OS syscall matrix pipe lrpc

Aegis 2.9 5.2s 22.6 10.4

Ultrix 33.7 5.2s 231 457


Cheetah Web Server

Exokernel web server performance features:– Transmits data directly from page cache w/o copying.

– Colocates hyperlinked files within filesystem.

– Network stack tuned to reduce packets by 20%.


Exokernel Portability

Apps that directly use exokernel aren’t portable to different architectures.

Exokernel tied closely to hardware.

Library operating systems can provide portability for other applications.

LibOSes can provide POSIX interface.

Can run multiple LibOSes on exokernel.


Microkernels in Use

MachUnderlying microkernel for UNIX systems.Examples: Mac OS X, MkLinux, NeXTStep

QNXPOSIX-compliant real-time OS for embedded sys.Fits on a single floppy.Underlying microkernel for Cisco IOS XR.

SymbianMicrokernel OS for cell phones.


Key Points1. Microkernel provides minimal features

1. Address spaces2. IPC3. Scheduling

2. Microkernel advantages1. Flexibility2. Safety3. Modularity

3. Early microkernels were slow, but flexible memory/disk policies can allow for superior application performance.

4. Exokernels focus on separation of protection from abstraction instead of focusing on user/kernel divide.


References1. Dawson R. Engler, M. Frans Kaashoek, James O'Toole Jr., “Exokernel: An Operating System

Architecture for Application-Level Resource Management,” Proc 15th Symposium on Operating Systems Principles (SOSP), December 1995.

2. David Golub, Randall Dean, Alessandro Forin, Richard Rashid, “UNIX as an Application Program,” Proceedings of the Summer 1990 USENIX Conference, pages 87-95, June 1990.

3. Per Brinch Hansen. “The Nucleus of a Multiprogramming System,” Communications of the ACM 13(4):238-241, http://brinch-hansen.net/papers/1970a.pdf, April 1970.

4. Hermann Härtig, Michael Hohmuth, Jochen Liedtke, Sebastian Schönberg, “The performance of μ-kernel-based systems”. Proc. 16th ACM symposium on Operating Systems Principles (SOSP), 1997.

5. Jochen Liedtke. “On µ-Kernel Construction,” Proc. 15th ACM Symposium on Operating System Principles (SOSP), December 1995

6. Jochen Liedtke, “Towards Real Microkernels,” Communications of the ACM, 39(9):70-77, September 1996.

7. Avi Silberchatz et. al., Operating System Concepts, 7th edition, http://codex.cs.yale.edu/avi/os-book/os7/online-dir/Mach.pdf, 2004.

8. Michael M. Swift, Brian N. Bershad, and Henry M. Levy, “Improving the Reliability of Commodity Operating Systems,” Proc. 19th ACM Symposium on Operating System Principles (SOSP), Oct. 2003.

9. Andrew S. Tanenbaum, Modern Operating Systems, 3rd edition, Prentice-Hall, 2005.10. Andrew S. Tanenbaum, J. Herder, and H. Bos. “Can We Make Operating Systems Reliable and

Secure?” IEEE Computer, May 2006. 11. Andrew S. Tanenbaum, J. Herder, and H. Bos. “A Lightweight Method for Building Reliable

Operating Systems Despite Unreliable Device Drivers,” TR IR-CS-018, http://www.minix3.org/doc/reliable-os.pdf, 2006.

12. Andrew S. Tannenbaum, “Tanenbaum-Torvalds Debate: Part II,” http://www.cs.vu.nl/~ast/reliable-os/, 2006.

http://brinch-hansen.net/papers/1970a.pdf

http://codex.cs.yale.edu/avi/os-book/os7/online-dir/Mach.pdf

http://www.minix3.org/doc/reliable-os.pdf

http://www.cs.vu.nl/~ast/reliable-os/

Documents

CSC 660: Advanced Operating SystemsSlide #1 CSC 660: Advanced OS Microkernels