210 likes | 470 Views
Testing and Analysis of Device Drivers. Supervisor: Abhik Roychoudhury Author: Pham Van Thuan. Agenda. Problem statement Literature review Open research problems RQ-1. Subsystem aware test case generation RQ-2. Testing device protocol violation bugs Preliminary work.
E N D
Testing and Analysis of Device Drivers Supervisor: AbhikRoychoudhury Author: Pham Van Thuan
Agenda • Problem statement • Literature review • Open research problems • RQ-1. Subsystem aware test case generation • RQ-2. Testing device protocol violation bugs • Preliminary work
Problem statement • Device driver bugs are the main cause of OS crashes (85% crashes of Windows XP, 53% out of 1000 defects in Linux kernel 2.6.9). • How to find these bugs and/or prevent their negative effects. Software model checking Testing and analysis Isolating and tolerating Modifying current driver architectures Static analysis + code transformation Dynamic symbolic execution based testing
Linux device driver architecture Linux device driver architecture
Classification of common device driver bugs • Incorrect use of kernel-internal APIs • Incorrect implementation of the device’s protocol • Concurrency related bug • Memory access violation • Resource leak
Program analysis and Software model checking Static analysis Composite static analysis Configurable Software Verification Abstract interpretation Predicate abstraction + CEGAR Lazy abstraction CPAChecker SLAM, SATABS BLAST CBMC Software model checking CEGAR Bounded model checking CBMC
Symbolic Execution Compositional DSE Dynamic symbolic/concolic execution (DSE) L1 POPL’2007 L2 DSE + Selective symbolic execution L3 DART, KLEE, MAYHEM L4 L4 ASPLOS’2011 L5 DSE + State merging L6 L6 L7 L8 PLDI’2012 DSE + Interpolation FSE’2013 Static symbolic execution (SSE) DSE + SSE ISCE’2014 Calysto (ICSE’2008)
SymDrive: Testing drivers without devices • Static analyzer + code transformation • Test framework • Symbolic device
Open research problems • Scalability problem • Reachability problem • Test oracle – Assertion generation • Driver/Device interface violation testing
RQ-1. Subsystem aware test case generation Example of Linux driver subsystems
Subsystem aware test case generation Hierarchical view of a USB keyboard device driver
RQ-1.1. Assertion generation • Use static analyzer to detect potential buggy locations • Use code transformation technique to insert calls to run-time checkers. • Design checkers for the interface between the kernel and device drivers (Checker can be used for testing several device drivers)
RQ-1.2. Test program generation Libc, system calls invocations Open(…) Read(…) Write(…) … Close(…) Test program C library Generic interfaces: File_operations, block_device_operations, net_device_ops System call interface + Virtual File System Driver subsystem core Subsystem specific functions Device Driver Driver entry points
Skeleton of a driver subsystem call graph • Build the skeleton for each driver subsystem. • Generate test program(s) based on the paths in the skeleton of the driver subsystem under test
RQ-1.3. Driver entry points and assertions reachability Test program Test program C library C library System call VFS System call VFS Driver core Driver core Entry points Device Driver Device Driver Assertion Driver entry points reachability Assertions reachability
RQ-2. Testing device protocol violation bugs • A device driver may violate the protocol of the corresponding hardware device (packet format, sequence of packet transfer, time …) • A Hardware device may run in unexpected states due to bugs in the device driver. Device driver Bus controller + Bus driver Virtual hardware device
RQ-2.1. Virtual symbolic device modeling • Symbolic input/output interfaces • Internal working blocks to emulate real hardware device(s) Virtual Symbolic Device S2E Symbolic Device QEMU Virtual hardware device
RQ-2.2. Assertion & Annotation generation • Assertion • Assert valid register settings • Assert a correct working state • Assert a correct packet format (received from device driver) • Annotation • Add constraints for the format of packets to be sent to a device driver informal technical documents (datasheets) ? Assertion, annotation
Preliminary work • Control Flow Graph (CFG) • Use profiling information to resolve indirect calls, indirect jumps. • Control Dependency Graph (CDG) • CDG works with CFG and the skeleton of the subsystem call graph to guide path exploration and prune uninteresting paths.
Preliminary work Test program • Search algorithm replays a path to reach a predefined location (a driver entry point is an example). • Integrate Z3 constraint solver into S2E framework for checking un-sat core, solving string constraints (Z3-str) … (not supported by STP, the default solver of S2E) C library System call VFS Driver core Device Driver Assertion