A Survey of Dynamic Techniques for Detecting Device Driver Errors Olatunji Ruwase LBA Reading Group 18 th May 2010
Dec 30, 2015
A Survey of Dynamic Techniques for Detecting Device Driver Errors
Olatunji Ruwase
LBA Reading Group 18th 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) <dom,perms>
• Permissions: {read,write,type, <call, arg stack size>}• 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
SafeDrive XFI BGI LifeguardCheck/Access atomicity No No No YesWorks on driver binaries No Yes No YesComplex interposition library Maybe Yes Yes NoRestrictions on driver code Yes Yes Yes NoError containment required No No No Yes