CS 443 Advanced OS David R. Choffnes, Spring 2005 Application Performance and Flexibility on Exokernel Systems M. F. Kaashoek, D.R. Engler, G.R. Ganger,H.M. Briceno, R. Hunt, D. Mazieres, T. Pinckney, R. Grimm, J. Jannotti, K. Mackenzie MIT LCS Appears in SOSP 1997 Presented by: David R. Choffnes
29
Embed
CS 443 Advanced OS David R. Choffnes, Spring 2005 Application Performance and Flexibility on Exokernel Systems M. F. Kaashoek, D.R. Engler, G.R. Ganger,H.M.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
CS 443 Advanced OS
David R. Choffnes, Spring 2005
Application Performance and Flexibility on Exokernel Systems
M. F. Kaashoek, D.R. Engler, G.R. Ganger,H.M. Briceno, R. Hunt, D.
Mazieres, T. Pinckney, R. Grimm, J. Jannotti, K. Mackenzie
MIT LCSAppears in SOSP 1997
Presented by: David R. Choffnes
2
Why Exokernels?
Application demands vary widely– Current OSs provide high-level interfaces and
attempt to optimize for some “average-case” workload
– Penalty for certain applications can be high– It would be better to give these untrusted
applications direct access to hardware
3
Exokernel Architecture Overview
Goals– Limit OS (kernel) functionality to managing protection (and
safe sharing) of hardware resources– Allow “applications” to manage resources
• Many of these “applications” will perform management typical of monolithic OSs – called library operating systems (libOSes)
• Traditional applications will then link to the libOSes instead of linking to a monolithic kernel
Claim– Any programmer can specialize at libOS without affecting
the rest of the system
Too much responsibility in hands of app. programmer?
4
Conventional OS user interface
User process
Kernelprotects and manages
all the system resources
User process
System calls
5
Exokernels
Exokernelprotects but
does not managesystem resources
User process User process
6
LibOSes
Exokernel
User process
libOS
User process
libOS
7
Purpose of Paper
Proof of concept: show that exokernels can introduce new interfaces that separate protection from management
Show that exokernels do not limit performance of ordinary apps
Show that apps can use exokernel to improve performance compared to traditional kernel
8
Related Work (“Anything you can do I can do better”)
Recast the debate over kernel architecture– Since exokernel operates at such a low level, it is
“orthogonal” to the debate over monolithic/ukernel– Anything done to improve performance in a
ukernel approach can and should be done in exokernel applications
Virtual Machines– Solve the extensibility problem, but
compartmentalize applications, which can lead to inefficiency
Exokernels allow downloading of code
9
Exokernels in a Nutshell (1)
Exokernel principles– Separate protection from management
• Allocation, revocation, sharing and tracking of ownership
– Expose allocation• Allows apps to fully control what they allocate
– Expose names• Allows apps to use physical names, eliminating overhead of
virtualization
– Expose revocation• Allow apps to recover from revocation instead of simply killing them
– Expose information• Allow app to know just about everything that the kernel knows
10
Exokernels in a Nutshell (2)
Kernel support for protected abstractions– Challenge: allow high-level access control without
mandating an implementation or hindering application control of resources
– Design techniques• Same access control for all resources• Binding of hardware resources as software abstractions
– Buffer cache example
• Support downloading of code for abstractions– Allows extensibility to new forms of protection not
represented by hardware
– Abstractions reside in kernel (cheap shot at ukernels)
11
Microkernels in a Nutshell (3)
Protected sharing– LibOSes can trust applications not to muck with
resources provided by exokernel, but cannot trust other libOSes that may have the same access.
• E.g., the fork problem– Exokernel provides four mechanisms to maintain
invariants in shared abstractions• Software regions (region can be read only through
system call)• Hierarchically-named capabilities (protect against buggy
– Eliminates the need for locks– Can still lead to livelock?
12
Microkernels in a Nutshell (3)
– Optimize shared abstraction implementation according to level of trust
• Mutual trust– Similar to monolithic kernel programming
• Unidirectional– Protect shared resources from untrusted side
• Mutual distrust (defensive programming)– Worst case and rare– Must account for all kinds of attacks/problems
13
Multiplexing Disk Storage(or: How I Learned to Stop Worrying and Love the Exokernel)
Challenge– Support multiple concurrent file systems without
partitioning– Give as much control as possible to libFSes as
possible while protecting files from unauthorized access
– Allow file systems to define arbitrary file formats
Implementation: Stable Storage System– Simple/lightweight capability for new file formats– Allow safe sharing of disk blocks among libFSes– Efficient access– Allow cache sharing while supporting invariants
14
XN (One Hack to Rule them All)
Provides– Access to storage at level of disk blocks– Public-readable buffer cache registry– Free maps
Purpose is to determine the access rights of a principal to a given disk block efficientlyChallenge: multiple file formatsSolution: UDF (untrusted deterministic functions)– Translate metadata from associated file format to
a language that the kernel can understand– Stored in disk structures called templates
15
XN (continued)
UDF allows libFS to define each of its types once per file system– Better than separating capabilities from (meta)data blocks or
using self-descriptive blocks
Requirements for XN– Every operation on disk data must be guarded
• Implemented at bind time (when page associated with disk block is loaded into page table)
– Determine access rights unambiguously (use libFS’s metadata)
– Prevent crashes from corrupting FS (no writing pointers to uninitialized data, no freeing block until there are no pointers to it)
16
XN (continued)
For protected sharing among libFS’s:– Coherent caching of disk blocks (in-kernel,