1 / 15

Recovering Device Drivers

Recovering Device Drivers. Michael Swift, Muthukaruppan Annamalai, Brian Bershad, Henry Levy. Presented by Radu Teodorescu. Motivation. 85% Windows XP crashes - driver related Linux drivers 7X more bugs than the kernel Why do drivers fail?

trevor-mccray
Télécharger la présentation

Recovering Device Drivers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Recovering Device Drivers • Michael Swift, Muthukaruppan Annamalai, Brian Bershad, Henry Levy Presented by Radu Teodorescu

  2. Motivation • 85% Windows XP crashes - driver related • Linux drivers 7X more bugs than the kernel • Why do drivers fail? • There are so many of them! (70% of Linux kernel, 35,000 in Windows XP) • Developed by many third party suppliers • Privileged access inside your kernel!

  3. Solution • Change kernel-driver interaction • Detect driver failure • Isolate fault, avoid kernel corruption • Conceal driver failure, service requests • Restart & initialize driver NOOKS SHADOW DRIVERS

  4. Outline • Shadow drivers & NOOKS • Results • Limitations • Discussion

  5. Shadow Drivers • Kernel agents attached to each device driver • Allow transparent restart of failed drivers • Implements both kernel and driver class interfaces Shadow Driver

  6. Shadow Drivers • Passive mode: normal operation • monitor communication driver-kernel • Active mode: fault detected • restart, initialize, transfer state • respond to calls from kernel

  7. Passive mode Active mode

  8. Active Mode Recovery • Stop the failed driver • Reinitialize driver from clean state • Transfer relavant state to new driver • At the same time: service kernel requests!

  9. Shadow Driver Needs • Coordination - management of shadow drivers - Shadow manager • Redirection mechanism - transparent monitoring and recovery - Taps • Isolation service - prevents driver errors from corrupting the kernel - NOOKS • Object tacking service - track kernel objects created by the driver - NOOKS

  10. NOOKS* • Idea: isolate the OS from driver failures • NOOKS functions: • isolation • object tracking • fault detection *SOSP’03

  11. System Architecture

  12. Fault Injection Outcome

  13. Limitations • Drivers that cannot be reloaded dynamically • Permanent faults • Ad-hoc driver-kernel communication • Irreversible side effects • Fault isolation is hard • Failure detection imperfect

  14. Discussion • Kernel built-in transparent driver recovery? • How would the system be simplified? • Clear bounds between kernel/driver space • Standard communication, clean interface • More stateless drivers, easier to restart • More?

  15. Thank you!

More Related