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

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