A Survey of Dynamic Techniques for Detecting Device Driver Errors Olatunji Ruwase LBA Reading Group 18 th May 2010

Introduction Terminology – Device Drivers in Windows – (Kernel) Modules in Linux Improve OS extensibility and customization – Use new hardware devices – Increase application performance Browsers RAMDISK Reduce OS Reliability – Typically written by non kernel developers – Linux Makes up over 50 % of source code 7X bug density relative to rest of kernel – 90 % of Windows XP crashes

Survey Methodology Instrumentation based techniques: SafeDrive, XFI, BGI – Protect against buggy, but not malicious drivers – Generic programming errors (23 % of Linux driver errors) Detected driver errors – No discussion of recovery from driver errors Key Ideas – Metadata – Instrumentation Limitations – False negatives – Not applicable to driver binaries – Interposition library complexity i.e kernel & driver function wrappers – Driver code restrictions Comparison to Lifeguard approach

SafeDrive [Zhou et al OSDI ‘06] Detected driver errors – Out-of-bounds access Key Ideas – Annotate driver and kernel header sources with pointer bounds information – Compile-time instrumentation of driver with bounds checks based on annotations – Kernel wrappers to track memory (de)allocation

Annotations & Runtime checks Linux e1000 network card driver

SafeDriver Compilation of SafeDrivers Block Diagram of SafeDriver in Linux

SafeDrive Limitations Concurrency breaks check/access atomicity Not applicable to driver binaries False Negatives – No memory access control i.e (r,w,x) violations Code restrictions –No casts between “significantly” different types –Array & length encapsulated in struct Annotation burden –4 % of driver source code –~ 943 LOC of kernel headers Fairly complex interposition library

XFI [Erlingsson et al OSDI’06] Detected driver errors –Unpermitted (r,w,x) memory access –Illegal control flow transfers Key Ideas – Accessible memory of driver Data sections and allocated memory Pointers passed by kernel – Binary rewriting & verification to load only instrumented drivers Control flow, stack overflow, memory range checks – Two stacks for driver execution Verified scoped stack: non pointer addressable local vars including return addr Allocation stack: pointer addressable local variables – Kernel & driver wrappers to maintain accessible memory and stacks

XFI Checks Call instruction check Memory write checks

XFI Module

XFI Limitations Concurrency breaks check/access atomicity Improper use of kernel API possible False Negatives –Buffer overflows –Wild pointer accesses Driver code restrictions – No global/static variable access via pointers – No privileged x86 instructions Complex interposition library

BGI [Castro et al SOSP ‘09] Detected driver errors – Unpermitted(read,write, type) memory access – Unpermitted control flow transfers – Misuse of kernel objects and API Key Ideas – Target drivers using Windows Driver Model(WDM) – Protection domains: Kernel & Driver – Byte-granularity access control lists(ACL) Permissions: {read,write,type, } Maintained by compiler instrumentation and kernel wrappers

BGI wrappers(initialize, insert)

BGI Drivers Generating a BGI driver Kernel address space with BGI drivers

BGI Limitations Concurrency breaks check/access atomicity Not applicable to driver binaries Driver code restrictions due to WDM (good ?) – No direct kernel object modification – No inline assembly – Proper static types of variables i.e no void * Kernel/driver complexity increased by wrappers – 16.7 KLOC, 262 kernel, 84 driver wrappers False Negatives – Buffer overflows not detected – Any function with same arg stack size could be called

Comparison to Lifeguard approach SafeDriveXFIBGILifeguard Check/Access atomicityNo Yes Works on driver binariesNoYesNoYes Complex interposition libraryMaybeYes No Restrictions on driver codeYes No Error containment requiredNo Yes