Defensive Driving: Guarding Operating System from Device Driver Bugs and Crashes

1. Defensive Driving: Guarding Operating System from Device Driver Bugs and Crashes Ganesh Bikshandi, Jia Guo and Justin Trobec

2. Motivation • Operating system crashes are a huge problem today • 5% of Windows systems crash every day • Device drivers are the biggest cause of crashes • Drivers cause 85% of Windows XP crashes • Drivers are 7 times more bugs than the kernel in Linux

3. Common bugs • Illegal Memory Access • Data Corruption • Illegal Parameters • Resource Hoarding

4. Why a driver crashes OS? • Driver usually runs in a privileged kernel mode. • Bugs in drivers may corrupt vital kernel data • OS is conservative on exceptions caused by kernel process. User Program Kernel Driver

5. Solution • Isolation of Kernel from Driver • Containing the faults • Restricting the driver’s behavior • Recovery • Continue the application • (Not in our scope)

6. Possible Approaches • Driver runs in user space • Driver runs as a kernel level process • Driver runs inside a kernel in a light weight protection domain

7. Driver runs in user space • Pros • Full isolation • Driver crashes cannot affect the OS • Cons • Performance penalty to change privilege level • Need to modify the drivers. • Potential Context Switch • IPC

8. Driver runs as a kernel process • Driver as a separate process in kernel which is limited in its address space. • Pros • Clean separation of between kernel and driver execution • Easier implementation • Cons • IPC

9. Our Approach • Borrowed from Nooks • Lightweight protection domain • A Module that has: • Kernel privileges • Restricted access to Kernel Data • Normally Read only access • Part of kernel

10. Domain Switch • Kernel to Driver • Switch to less privileged • Driver to Kernel • Switch to more privileged • How to perform the switch • Wrappers

11. Domain Switch serialCOM->getChar() Kernel Code TheKernel-> foo() Driver Code

12. Domain Switch Wrappers OurSerialCOM->getChar() Kernel OurKernel-> foo() Driver

13. Domain Switch • Who performs the domain switch • XPC (Extended Procedure Call) • SwitchAndInvoke • What does a domain have • Page tables • Heap • Stack

14. Why this design? • No context switch • No System call • No IPC • No Privilege change • Kernel/Driver calls are minimal • Minimal Code changes • Kernel and Drivers

15. Nooks in Choices: Protection Domains • Choices already contains Domain objects • Can serve as basis for our Protection Domains • May need further modification of memory systems • e.g. allocators for checked object allocation? • e.g. SwitchAndInvoke may be more appropriate as part of the Domain object

16. Scope • Recoverability and Bug Reduction • Not perfect isolation, Not security • Software Only Solution • Does not rely on hardware mechanisms • C++ Drivers Only • Ideally, all languages • Can still provide lots of usefulness w/C++ • No Recovery Manager • Nooks has one, we’ll need one, scoping it out for this iteration

17. Wrapping Driver Calls • Calls into the driver • Choices lacks common driver interface • Create a base driver class • Requires (very) minor modification of each driver • Only handles kernel  driver, not driver  kernel • Would also allow us to overload some operators • Overload assignment (=) for reference tracking • Overload dereference (->) for reference checking

18. Wrapping Driver Calls • Calls into the kernel • Subclass kernel • Could potentially be used as a way to wrap kernel • Drivers could call other classes • Make kernel calls through special purpose function • SwitchAndInvoke • Would require more extensive alteration of drivers

19. Status and Future Work • Hacked Choices • Explored the Design Space • Finalized Preliminary Design • Implementation and Design Tweaks • Test for Correctness and Performance • Write Paper 