Improving the Reliability of Commodity Operating Systems
This research paper discusses the challenges and solutions in enhancing the reliability of commodity operating systems by addressing system failures caused by kernel extensions. The Nooks approach isolates extensions within protection domains, allowing them to reside in the kernel address space with minimal code changes. The goal is to enable existing kernel extensions to execute safely in commodity kernels, focusing on practicality, compatibility, and efficiency.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
IMPROVING THE RELIABILITY OF COMMODITY OPERATING SYSTEMS Michael M. Swift Brian N. Bershad Henry M. Levy University of Washington
Key Idea Kernel extensions are a major source of system failures Nooks isolates extensions within lightweight protection domains inside the kernel address space Requires little or no changes to extension and kernel code Still prevents most system failures
INTRODUCTION Want to allow existing kernel extensions to execute safely in commodity kernels because Computer reliability remains an unsolved issue Kernel extensions are increasingly popular in Windows and Linux Account for most system failures (85% for Windows XP)
Why? Programmers writing device drivers are often less experienced than kernel programmers Number of variants prevent us from testing them completely
The Nooks approach Works with commodity operating systems Requires little or no changes to extension and kernel code Prevents most but not all system failures Let kernel extensions reside in the kernel address space Solution is practical, backward-compatible and efficient
The challenge Extensibility Mach Linux Windows (microkernel) Speed Safety Unix
PREVIOUS WORK (I) Capability-based architectures, ring and segment architectures: Enable construction and isolation of privileged subsystems. Slow and do not address recovery issues
PREVIOUS WORK (II) Microkernels: Put extensions into separate address spaces Slow and do not address recovery issues Database recovery techniques: Atomic transactions Work well for file system Often awkward and slow
PREVIOUS WORK (III) Type-safe programming languages: Must rewrite the kernel Static analysis of extensions: Can detect some errors
PREVIOUS WORK (III) Virtual machines: Can reduce the amount of code that can crash whole machine Fails if extension executes inside the virtual machine monitor VM VM VM VM Monitor Hardware
REQUIRED MODIFICATIONS Approach Capability architecture Microkernels Type-safe languages New driver arch. Atomic transactions Virtual machines Static analysis Nooks HW Yes No No No No No No No OS Yes Yes Yes Yes No No No No Ext. Yes Yes Yes Yes Yes Yes No No
NOOKS Design for fault-resistance, not fault-tolerance: System must prevent and recover from mostextension mistakes Occupy middle ground between unprotected (Linux, Windows) and safe (SPIN, Java VM) Design for mistakes, not abuse: Exclude malicious behavior
Nooks goals Isolation: Isolate kernel from extension failures Detect extension failures before they corrupt kernel Automatic recovery from extension failures Backward compatibility with existing systems and extensions
Nooks functions New system reliability layer: the Nooks Isolation Manager (NIM) OS Kernel Object Tracking Recovery Isolation Interposition Kernel extensions
Nooks isolation mechanisms Every extension executes within its own lightweight kernel protection domain Communication between kernel and extensions must go through new kernel service, the Extension Procedure Call (XPC) Similar to an RPC between two processes located on the same machine (Lightweight RPC)
Lightweight protection domains Provide protection by having extensions execute with a different page table giving them Read/write access to their own pages Read only access to other kernel pages Kernel (read only) Extension (R/W)
Lightweight protection domains Lightweight solution Extensions execute in kernel mode A malicious extension could Switch back to the kernel s page table Another could misuse DMA
Nooks interposition mechanisms Ensure that All extension-to-kernel and kernel-to-extension control flow goes through Nooks XPC mechanism All data transfers between kernel and extension go through Nooks object tracking code All interfaces are done through wrappers, similar to the stubs of an RPC package
Nooks object tracking functions Maintain a list of kernel data structures accessed by each extension Control all modifications to these structures Provide object information for cleanup if object fails
Nooks object tracking functions Extensions cannot directly modify kernel data structures Object tracking code will: Copy kernel data structures into extension address space Copy them back after changes have been applied Perform checks whenever possible
Nooks recovery functions Detect and recover from various extension faults: When an extension improperly invokes a kernel function When processor raises an exception
Nooks recovery functions Recovery helped by Nooks isolation mechanisms: All access to kernel structures are done through wrappers Nooks can successfully release extension-held kernel structures
IMPLEMENTATION Inside Linux 2.4.18 kernel on Intel x86 architecture Linux kernel provides over 700 functions callable by extensions over 650 extension-entry functions callable by the kernel Most interactions between kernel and extensions go through function calls
Nooks Linux Kernel Nooks Isolation Manager Interposition Extension Interposition Extension Extensions are wrapped by Nooks wrapper stubs
Details 22,000 lines of code Linux kernel has 2.4 million lines Makes no use of Intel x86 protection rings Extensions execute at same protection level as kernel
Isolation Two parts: memory management: to implement lightweight protection domains extension procedure call (XPC)
Memory management All components share the same kernel address space Each extension executes in a separate lightweight protection domain Extension has: Read-only access to kernel Read-write access to its own domain
Lightweight protection domains Each lightweight protection domain has A synchronized copy of the kernel page table Its own heap, a pool of stacks and other private data structures Changing protection domains requires a change of page tables Results in a TLB flush! Performance degradation No protection against DMA misuse by extensions
Interposition (I) Done by wrapper stubs all executing in kernel protection domain: Before the call when kernel calls an extension After the call when an extension calls the kernel Wrappers: Check parameters for validity Implement call by value and result
Passing by value and result Variable i is increased after caller receives server s reply Caller: i = 0; abc(&i); i = 0 abc(int *k){ (*k)++; } i = 1 i
Interposition (II) Writing wrappers is not an easy task: Requires knowing how parameters are used Significant amount of wrapper sharing among extensions Especially when extensions share same functionality
Object tracking Records kernel objects and types manipulated by extensions
Recovery Mostly through undoing
Limitations Cannot prevent extensions from executing privileged instructions that would corrupt the kernel Cannot prevent infinite loops inside an extension Prevented by Linux semantics to do a thorough check of the parameters passed to the operating system Current implementation of recovery assumes that extensions can be killed and restarted
Transparency Neither the extension not the kernel is aware of the Nooks layer In reality, must sometimes modify a few lines of extension code
Reliability Tested eight extensions Two sound card drivers Four Ethernet drivers A Win95 compatible file system (VFAT) An in-kernel Web server Injected 400 faults 317 resulted in extension failures
Test results Nooks eliminated 99% of the crashes observed with native Linux 313 out of 317 Nooks isslower VFAT benchmark spent 165s in the kernel instead of 29.5s for native Linux Web server could only serve about 6,000 pages/s instead of 15,000 pages/s for native Linux Ouch!
PERFORMANCE Ten percent performance penalty for sound and Ethernet drivers Sixty percent performance penalty for in-kernel web server (15,000 - 6,000)/15,000
Recovery errors Big problems with VFAT extension 90% of attempted recoveries resulted in on-disk corruption VFAT extension cannot be safely killed and restarted We should expect that!
CONCLUSIONS Nooks approach focuses on achieving backward compatibility Cannot provide complete isolation and fault-tolerance Can still achieve an extremely high level of operating system reliability Performance loss varies between 0 and 60 percent
