SlideShare a Scribd company logo
Fast and Precise Symbolic Analysis of
Concurrency Bugs in Device Drivers
Pantazis Deligiannis
Alastair Donaldson
Zvonimir Rakamarić
We acknowledge funding by a gift from Intel Corporation and from NSF CCF 1346756
The relative error-rate in device
driver code is up to 10 times higher
than the rest of the Linux kernel [1]
[1] Chou et al. An empirical study of operating systems errors. SOSP 2001
85% of the system crashes in
Windows XP are caused by faulty
device drivers [2]
[2] Swift et al. Improving the reliability of commodity operating systems. SOSP 2003
19% of the bugs in Linux device
drivers are due to concurrency issues,
such as data races [3]
[3] Ryzhyk et al. Dingo: Taming device drivers. EuroSys 2009
Data races, can lead to subtle, hard
to debug errors in complex programs
such as device drivers
How to efficiently detect them?
Overview of our approach
Concurrent Driver
Overview of our approach
Concurrent Driver
Sequential Driver
(sound over-approximation)
transform
Overview of our approach
Concurrent Driver
Sequential Driver
(sound over-approximation)
Symbolic
Lockset Analyser
(identify all potential races)
transform
Overview of our approach
Concurrent Driver
Sequential Driver
(sound over-approximation)
Symbolic
Lockset Analyser
(identify all potential races)
Symbolic Verifier
(precise but bounded exploration)
We developed in this work …
exploit race
info to speedup
trace
transform
Concurrent Driver
EP1 EP2 EPN…
For each driver …
EP Pair
Concurrent Driver
EP1 EP2 EPN…
Consider every pair of
entry points that can
execute concurrently
EP1 EP2
EP Pair
EP1 EP3
EP Pair
EPM EPN
…
For each driver …
EP Pair
EP1 EP2
For each pair …
EP Pair
EP1 EP2
Sequential Pair
call EntryPoint1
call EntryPoint2
Call 2 entry points in sequence
(order, i.e. schedule, does not
matter due to lockset analysis)
Sequentialize
For each pair …
Sequential Pair
call EntryPoint1
call EntryPoint2
For each pair …
Sequential Pair
call EntryPoint1
call EntryPoint2
Soundly model the effects of any
other concurrently running EPs
by over-approximating read
accesses to shared memory
For each pair …
Sequential Pair
call EntryPoint1
call EntryPoint2
Instrument entry points
with additional state to
record locksets for
symbolic lockset analysis
Soundly model the effects of any
other concurrently running EPs
by over-approximating read
accesses to shared memory
For each pair …
Sequential Pair
call EntryPoint1
call EntryPoint2
Instrument entry points
with additional state to
record locksets for
symbolic lockset analysis
Soundly model the effects of any
other concurrently running EPs
by over-approximating read
accesses to shared memory
Attempt to verify race-freedom
by asserting that all accesses to
each shared memory location
are consistently protected by at
least one common lock
For each pair …
EP Pair
Good reason: we can symbolically
analyse each pair of entry points in
parallel (but we leave this for future work)
EP1 EP2
EP Pair
EP1 EP3
EP Pair
EPM EPN
…
Why pairwise analysis?
Lightweight data race detection method:
- proposed in Eraser [4], a dynamic race detector
Lockset analysis
[4] Savage et al. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. TOCS 1997
Lightweight data race detection method:
- proposed in Eraser [4], a dynamic race detector
- key idea: track sets of locks that consistently protect
each memory location S during program execution
Lockset analysis
[4] Savage et al. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. TOCS 1997
Lightweight data race detection method:
- proposed in Eraser [4], a dynamic race detector
- key idea: track sets of locks that consistently protect
each memory location S during program execution
- if the lockset of S ever becomes empty, report a
potential race on S
Lockset analysis
[4] Savage et al. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. TOCS 1997
Lightweight data race detection method:
- proposed in Eraser [4], a dynamic race detector
- key idea: track sets of locks that consistently protect
each memory location S during program execution
- if the lockset of S ever becomes empty, report a
potential race on S
- this is because an empty lockset suggests that S may
be accessed simultaneously by two or more threads
Lockset analysis
[4] Savage et al. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. TOCS 1997
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
{ M, N } { M, N }
compute lockset
intersection at
access point
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
{ M, N } { M, N }
{ M } { M, N }
compute lockset
intersection at
access point
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
{ M, N } { M, N }
{ M } { M, N }
{ M } { M }
compute lockset
intersection at
access point
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
{ M, N } { M, N }
{ M } { M, N }
{ M } { M }
{ } { M }
compute lockset
intersection at
access point
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
{ M, N } { M, N }
{ M } { M, N }
{ M } { M }
{ } { M }
{ N } { M }
compute lockset
intersection at
access point
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
{ M, N } { M, N }
{ M } { M, N }
{ M } { M }
{ } { M }
{ N } { M }
{ N } { }
compute lockset
intersection at
access point
compute lockset
intersection at
access point
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
{ M, N } { M, N }
{ M } { M, N }
{ M } { M }
{ } { M }
{ N } { M }
{ N } { }
compute lockset
intersection at
access point
warning: access
to A may not be
consistently
protected
Program CLST1 CLST2 LSA
Initial { } { } { M, N }
T1
lock (M);
lock (N);
write (A);
unlock (N);
write (A);
unlock (M);
T2
lock (N);
write (A);
unlock (N);
{ M } { M, N }
{ M, N } { M, N }
{ M, N } { M, N }
{ M } { M, N }
{ M } { M }
{ } { M }
{ N } { M }
{ N } { }
{ } { }
compute lockset
intersection at
access point
warning: access
to A may not be
consistently
protected
Advantages of lockset analysis:
Advantages of lockset analysis:
- easy to implement, lightweight, has the
potential to scale well (in contrast with
happens-before based analyses)
Limitations of lockset analysis:
Advantages of lockset analysis:
- easy to implement, lightweight, has the
potential to scale well (in contrast with
happens-before based analyses)
Limitations of lockset analysis:
- imprecision (a violation of locking discipline is
not always a race)
Advantages of lockset analysis:
- easy to implement, lightweight, has the
potential to scale well (in contrast with
happens-before based analyses)
Limitations of lockset analysis:
- imprecision (a violation of locking discipline is
not always a race)
- code coverage in dynamic tools is limited by
execution paths that are explored
Advantages of lockset analysis:
- easy to implement, lightweight, has the
potential to scale well (in contrast with
happens-before based analyses)
Limitations of lockset analysis:
- imprecision (a violation of locking discipline is
not always a race)
- code coverage in dynamic tools is limited by
execution paths that are explored
- to counter the latter, we apply lockset analysis
in a symbolic context by analysing source code
Advantages of lockset analysis:
- easy to implement, lightweight, has the
potential to scale well (in contrast with
happens-before based analyses)
We use Read and Write Sets during
lockset analysis to keep track of shared
memory location accesses — not in
previous example for simplicity
Some other (driver-specific) optimisations
read our paper!
Boogie IVL
code, instrumented
with yields
Data Race
Reports
No Errors
(Under Given Bounds)
WHOOP
Error Traces
Z3
Chauffeur
SMACK
Linux driver
source code in C
Boogie
IVL code
llvm-IR
Linux
Environmental
Model
Instrumentation
Sequentialization
Invariant Generation
Boogie
Verification
Engine
CORRAL
A. Translation Phase B. Symbolic Lockset Analysis Phase C. Bug-Finding Phase
Clang /
LLVM
entry point
information
Toolchain
W
Inst
Sequ
Invari
Ve
Translation Phase
Chauffeur
SMACK
Linux driver
source code in C
Boogie
IVL code
llvm-IR
Linux
Environmental
Model
Clang /
LLVM
entry point
information
W
Inst
Sequ
Invari
Ve
Translation Phase
Chauffeur
SMACK
Linux driver
source code in C
Boogie
IVL code
llvm-IR
Linux
Environmental
Model
Clang /
LLVM
entry point
information
W
Inst
Sequ
Invari
Ve
Translation Phase
Chauffeur
SMACK
Linux driver
source code in C
Boogie
IVL code
llvm-IR
Linux
Environmental
Model
Clang /
LLVM
entry point
information
Debugging information is preserved so that
we can map bugs back to C source code
Symbolic Lockset Analysis Phase
ACK
Boogie
IVL code
entry point
information
Data Race
Reports
WHOOP
Z3
Instrumentation
Sequentialization
Invariant Generation
Boogie
Verification
Engine
Boogie IVL
code, instrumented
with yields
No Errors
(Under Given Bounds)
Error Tr
CORRAL
Symbolic Lockset Analysis Phase
ACK
Boogie
IVL code
entry point
information
Data Race
Reports
WHOOP
Z3
Instrumentation
Sequentialization
Invariant Generation
Boogie
Verification
Engine
Boogie IVL
code, instrumented
with yields
No Errors
(Under Given Bounds)
Error Tr
CORRAL
Challenges and Solutions
Aliasing is a big challenge — we exploit LLVM
alias analyses and SMACK heap modelling
Scalability is a big issue — we generate
and infer invariants and perform
summarisation for modular verification
(each procedure verified in isolation)
read our paper!
- imprecision as it inherits the limitations of
lockset analysis
Limitations
- imprecision as it inherits the limitations of
lockset analysis
- sound over-approximation of shared state
and lock-free data structures can lead to
false alarms
Limitations
- imprecision as it inherits the limitations of
lockset analysis
- sound over-approximation of shared state
and lock-free data structures can lead to
false alarms
- do not currently handle interrupt handlers
in a special way, we just assume they
execute concurrently at all times (which
however is sound)
Limitations
To improve Whoop’s precision, we use
Corral [5], an industrial strength bug-finder
for device drivers from Microsoft Research
that is currently used by Microsoft in the
backend of the Static Driver Verifier (SDV)
Improving precision
[5] A. Lal, S. Qadeer, and S. K. Lahiri. A solver for reachability modulo theories. CAV 2012
The sequentialised program is bounded by
a number of context-switches per thread
[6] A. Lal and T. W. Reps. Reducing concurrent analysis under a context bound
to sequential analysis. CAV 2008
Corral uses the Lal-Reps sequentialisation
[6] to transform a concurrent program into
a non-deterministic sequential program
Bounded Bug-Finding
Bounded Bug-Finding
Corral can then explore the sequential
program to detect data races, encoded as
race-checking assertions
If a race is found, a trace (mapped on the
original C code) is reported to the user
Bug-Finding Phase
ie
de
int
ion
Data Race
Reports
WHOOP
Z3
Instrumentation
Sequentialization
Invariant Generation
Boogie
Verification
Engine
Boogie IVL
code, instrumented
with yields
No Errors
(Under Given Bounds)
Error Traces
CORRAL
State-space explosion
Corral inserts a context switch before
each shared memory access and at each
synchronisation point (e.g. lock/unlock)
Problem: this can be too coarse and state-
space can explode in large drivers!
State-space explosion
Corral inserts a context switch before
each shared memory access and at each
synchronisation point (e.g. lock/unlock)
Sound partial-order reduction
If our symbolic lockset analysis finds that
a given shared memory access is not
racy, then we do not instrument a context
switch before this memory access
This tames the sequentialisation and
can greatly speedup Corral as we
have found in our experiments
Sound partial-order reduction
If our symbolic lockset analysis finds that
a given shared memory access is not
racy, then we do not instrument a context
switch before this memory access
We applied our technique on 16 drivers from the
Linux 4.0 kernel:
- block, char, ethernet, nfc, usb and watchdog (250
— 7300 LoC)
- exploiting our symbolic lockset analysis we can
significantly accelerate Corral by 1.5-20x !
- in 1 driver there was slowdown, because we did
not manage to verify race freedom
- detected potential races (filled bug report, but
have not confirmed yet)
Evaluation
Whoop Corral Whoop + Corral
Benchmarks Time (sec)
# Context
Switches
CSB = 9
Time (sec)
# Context
Switches
CSB = 9
Time (sec)
generic_nvram 2.3 92 197.5 29 49.3
pc9736x_gpio 4.1 691 27337.6 167 1358.9
intel_scu_wd 2.4 314 1571.7 196 689.3
fs3270 3.2 321 T.O. (10 hours) 211 8883.0
intel_nfcsim 3.6 732 1539.9 601 278.0
sx8 2.8 227 21.4 217 24.3
Read the paper for more results!
Applied our symbolic lockset analysis on >1000
concurrency benchmarks from SVCOMP 2016:
- Early results: reducing Corral runtime by ~75%
- No bugs missed, gives more confidence in our
partial-order reduction!
We want to extend our Linux model so that we can
apply our technique on more drivers!
We want to experiment with applying our technique
on other Linux modules (e.g. filesystems)
New / Future work
Thanks!
http://www.doc.ic.ac.uk/~pd1113/
p.deligiannis@imperial.ac.uk
https://github.com/pdeligia/whoop
https://github.com/pdeligia/lockpwn

More Related Content

PDF
PDF
PDF
Omni ledger
PDF
FastBFT
PDF
ITFT_Semaphores and bounded buffer
PDF
Ekiden
PDF
Post Quantum Cryptography - Emerging Frontiers
PPT
DES Block Cipher Hao Qi
Omni ledger
FastBFT
ITFT_Semaphores and bounded buffer
Ekiden
Post Quantum Cryptography - Emerging Frontiers
DES Block Cipher Hao Qi

What's hot (20)

PPT
Stream ciphers presentation
PDF
An effective RC4 Stream Cipher
PPT
RC4&RC5
PPT
PDF
Defeating RSA Multiply-Always and Message Blinding Countermeasures
PPTX
Key reinstallation attacks forcing nonce reuse in wpa2
PDF
Next generation block ciphers
PPTX
Mutual Exclusion
PPTX
Information and data security pseudorandom number generation and stream cipher
PDF
Practical Differential Fault Attack on AES
PPT
Lecture 5
PPT
Chord Algorithm
PDF
2. Stream Ciphers
PPTX
Operating system 24 mutex locks and semaphores
PDF
Implementing STM in Java
PDF
St hack2015 dynamic_behavior_analysis_using_binary_instrumentation_jonathan_s...
PDF
CRYPTOGRAPHY AND NETWORK SECURITY
PPT
Lec11 semaphores
Stream ciphers presentation
An effective RC4 Stream Cipher
RC4&RC5
Defeating RSA Multiply-Always and Message Blinding Countermeasures
Key reinstallation attacks forcing nonce reuse in wpa2
Next generation block ciphers
Mutual Exclusion
Information and data security pseudorandom number generation and stream cipher
Practical Differential Fault Attack on AES
Lecture 5
Chord Algorithm
2. Stream Ciphers
Operating system 24 mutex locks and semaphores
Implementing STM in Java
St hack2015 dynamic_behavior_analysis_using_binary_instrumentation_jonathan_s...
CRYPTOGRAPHY AND NETWORK SECURITY
Lec11 semaphores
Ad

Viewers also liked (13)

PPT
The goMo™ Story
PPTX
Types of PANTOGRAPH
PPTX
Location based reminder
PPTX
Abes engineering college ghaziabad
DOCX
Location sharing and automatic message sender Android Application
PPTX
Training report of Electric Loco Shed
PPT
Dlw varanasi training ppt
DOC
Android Report
PPTX
Android ppt with example of budget manager
PPTX
NORTHERN RAILWAY EMU CAR SHED INDUSTRIAL TRAINING PRESENTATION
PDF
Final Year Project Report on Self Tacit Zone (Location Based Android App)
PPT
Use Case Diagram
PPTX
Railway loco ppt
The goMo™ Story
Types of PANTOGRAPH
Location based reminder
Abes engineering college ghaziabad
Location sharing and automatic message sender Android Application
Training report of Electric Loco Shed
Dlw varanasi training ppt
Android Report
Android ppt with example of budget manager
NORTHERN RAILWAY EMU CAR SHED INDUSTRIAL TRAINING PRESENTATION
Final Year Project Report on Self Tacit Zone (Location Based Android App)
Use Case Diagram
Railway loco ppt
Ad

Similar to Fast and Precise Symbolic Analysis of Concurrency Bugs in Device Drivers (20)

PDF
Man in the middle attacks
DOCX
Contents namp
DOCX
Contents namp
PPT
Iss lecture 2
PDF
Fast and Precise Symbolic Analysis of Concurrency Bugs in Device Drivers
PDF
Dsp file
PPT
Georgy Nosenko - An introduction to the use SMT solvers for software security
PPT
1 Cryptography Introduction_shared.ppt
PDF
IRJET- Securing Cloud Data Under Key Exposure
PDF
IRJET- Data Analysis for Braking System in Time Domain for Fault Diagnosis
PPT
PDF
A REVIEW ON NMAP AND ITS FEATURES
PDF
Cyber-Security Enhancements of Networked Control Systems Using Homomorphic En...
PPTX
Lattice based Merkle for post-quantum epoch
PPTX
Unit 1.pptx
PDF
STA STATIC TIMING ANALYSIS AND ITS USE HOW IT WORKS
PDF
A Typed Assembly Language for Non-interference.pdf
PDF
Specifying and Implementing SNOW3G with Cryptol
PDF
Cs8792 cns - Public key cryptosystem (Unit III)
PDF
Cryptosystem An Implementation of RSA Using Verilog
Man in the middle attacks
Contents namp
Contents namp
Iss lecture 2
Fast and Precise Symbolic Analysis of Concurrency Bugs in Device Drivers
Dsp file
Georgy Nosenko - An introduction to the use SMT solvers for software security
1 Cryptography Introduction_shared.ppt
IRJET- Securing Cloud Data Under Key Exposure
IRJET- Data Analysis for Braking System in Time Domain for Fault Diagnosis
A REVIEW ON NMAP AND ITS FEATURES
Cyber-Security Enhancements of Networked Control Systems Using Homomorphic En...
Lattice based Merkle for post-quantum epoch
Unit 1.pptx
STA STATIC TIMING ANALYSIS AND ITS USE HOW IT WORKS
A Typed Assembly Language for Non-interference.pdf
Specifying and Implementing SNOW3G with Cryptol
Cs8792 cns - Public key cryptosystem (Unit III)
Cryptosystem An Implementation of RSA Using Verilog

Recently uploaded (20)

PDF
How to Choose the Right IT Partner for Your Business in Malaysia
PDF
Nekopoi APK 2025 free lastest update
PDF
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
PDF
Understanding Forklifts - TECH EHS Solution
PDF
Design an Analysis of Algorithms I-SECS-1021-03
PDF
PTS Company Brochure 2025 (1).pdf.......
PPTX
Odoo POS Development Services by CandidRoot Solutions
PPTX
L1 - Introduction to python Backend.pptx
PDF
wealthsignaloriginal-com-DS-text-... (1).pdf
PDF
iTop VPN Free 5.6.0.5262 Crack latest version 2025
PPTX
Operating system designcfffgfgggggggvggggggggg
PDF
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
PPTX
Log360_SIEM_Solutions Overview PPT_Feb 2020.pptx
PDF
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
PDF
medical staffing services at VALiNTRY
PDF
Digital Strategies for Manufacturing Companies
PPTX
CHAPTER 2 - PM Management and IT Context
PDF
Upgrade and Innovation Strategies for SAP ERP Customers
PPTX
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
How to Choose the Right IT Partner for Your Business in Malaysia
Nekopoi APK 2025 free lastest update
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
Understanding Forklifts - TECH EHS Solution
Design an Analysis of Algorithms I-SECS-1021-03
PTS Company Brochure 2025 (1).pdf.......
Odoo POS Development Services by CandidRoot Solutions
L1 - Introduction to python Backend.pptx
wealthsignaloriginal-com-DS-text-... (1).pdf
iTop VPN Free 5.6.0.5262 Crack latest version 2025
Operating system designcfffgfgggggggvggggggggg
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
Log360_SIEM_Solutions Overview PPT_Feb 2020.pptx
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
medical staffing services at VALiNTRY
Digital Strategies for Manufacturing Companies
CHAPTER 2 - PM Management and IT Context
Upgrade and Innovation Strategies for SAP ERP Customers
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025

Fast and Precise Symbolic Analysis of Concurrency Bugs in Device Drivers

  • 1. Fast and Precise Symbolic Analysis of Concurrency Bugs in Device Drivers Pantazis Deligiannis Alastair Donaldson Zvonimir Rakamarić We acknowledge funding by a gift from Intel Corporation and from NSF CCF 1346756
  • 2. The relative error-rate in device driver code is up to 10 times higher than the rest of the Linux kernel [1] [1] Chou et al. An empirical study of operating systems errors. SOSP 2001
  • 3. 85% of the system crashes in Windows XP are caused by faulty device drivers [2] [2] Swift et al. Improving the reliability of commodity operating systems. SOSP 2003
  • 4. 19% of the bugs in Linux device drivers are due to concurrency issues, such as data races [3] [3] Ryzhyk et al. Dingo: Taming device drivers. EuroSys 2009
  • 5. Data races, can lead to subtle, hard to debug errors in complex programs such as device drivers How to efficiently detect them?
  • 6. Overview of our approach Concurrent Driver
  • 7. Overview of our approach Concurrent Driver Sequential Driver (sound over-approximation) transform
  • 8. Overview of our approach Concurrent Driver Sequential Driver (sound over-approximation) Symbolic Lockset Analyser (identify all potential races) transform
  • 9. Overview of our approach Concurrent Driver Sequential Driver (sound over-approximation) Symbolic Lockset Analyser (identify all potential races) Symbolic Verifier (precise but bounded exploration) We developed in this work … exploit race info to speedup trace transform
  • 10. Concurrent Driver EP1 EP2 EPN… For each driver …
  • 11. EP Pair Concurrent Driver EP1 EP2 EPN… Consider every pair of entry points that can execute concurrently EP1 EP2 EP Pair EP1 EP3 EP Pair EPM EPN … For each driver …
  • 12. EP Pair EP1 EP2 For each pair …
  • 13. EP Pair EP1 EP2 Sequential Pair call EntryPoint1 call EntryPoint2 Call 2 entry points in sequence (order, i.e. schedule, does not matter due to lockset analysis) Sequentialize For each pair …
  • 14. Sequential Pair call EntryPoint1 call EntryPoint2 For each pair …
  • 15. Sequential Pair call EntryPoint1 call EntryPoint2 Soundly model the effects of any other concurrently running EPs by over-approximating read accesses to shared memory For each pair …
  • 16. Sequential Pair call EntryPoint1 call EntryPoint2 Instrument entry points with additional state to record locksets for symbolic lockset analysis Soundly model the effects of any other concurrently running EPs by over-approximating read accesses to shared memory For each pair …
  • 17. Sequential Pair call EntryPoint1 call EntryPoint2 Instrument entry points with additional state to record locksets for symbolic lockset analysis Soundly model the effects of any other concurrently running EPs by over-approximating read accesses to shared memory Attempt to verify race-freedom by asserting that all accesses to each shared memory location are consistently protected by at least one common lock For each pair …
  • 18. EP Pair Good reason: we can symbolically analyse each pair of entry points in parallel (but we leave this for future work) EP1 EP2 EP Pair EP1 EP3 EP Pair EPM EPN … Why pairwise analysis?
  • 19. Lightweight data race detection method: - proposed in Eraser [4], a dynamic race detector Lockset analysis [4] Savage et al. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. TOCS 1997
  • 20. Lightweight data race detection method: - proposed in Eraser [4], a dynamic race detector - key idea: track sets of locks that consistently protect each memory location S during program execution Lockset analysis [4] Savage et al. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. TOCS 1997
  • 21. Lightweight data race detection method: - proposed in Eraser [4], a dynamic race detector - key idea: track sets of locks that consistently protect each memory location S during program execution - if the lockset of S ever becomes empty, report a potential race on S Lockset analysis [4] Savage et al. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. TOCS 1997
  • 22. Lightweight data race detection method: - proposed in Eraser [4], a dynamic race detector - key idea: track sets of locks that consistently protect each memory location S during program execution - if the lockset of S ever becomes empty, report a potential race on S - this is because an empty lockset suggests that S may be accessed simultaneously by two or more threads Lockset analysis [4] Savage et al. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. TOCS 1997
  • 23. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N);
  • 24. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N }
  • 25. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N }
  • 26. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N } { M, N } { M, N } compute lockset intersection at access point
  • 27. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N } { M, N } { M, N } { M } { M, N } compute lockset intersection at access point
  • 28. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N } { M, N } { M, N } { M } { M, N } { M } { M } compute lockset intersection at access point
  • 29. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N } { M, N } { M, N } { M } { M, N } { M } { M } { } { M } compute lockset intersection at access point
  • 30. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N } { M, N } { M, N } { M } { M, N } { M } { M } { } { M } { N } { M } compute lockset intersection at access point
  • 31. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N } { M, N } { M, N } { M } { M, N } { M } { M } { } { M } { N } { M } { N } { } compute lockset intersection at access point compute lockset intersection at access point
  • 32. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N } { M, N } { M, N } { M } { M, N } { M } { M } { } { M } { N } { M } { N } { } compute lockset intersection at access point warning: access to A may not be consistently protected
  • 33. Program CLST1 CLST2 LSA Initial { } { } { M, N } T1 lock (M); lock (N); write (A); unlock (N); write (A); unlock (M); T2 lock (N); write (A); unlock (N); { M } { M, N } { M, N } { M, N } { M, N } { M, N } { M } { M, N } { M } { M } { } { M } { N } { M } { N } { } { } { } compute lockset intersection at access point warning: access to A may not be consistently protected
  • 35. Advantages of lockset analysis: - easy to implement, lightweight, has the potential to scale well (in contrast with happens-before based analyses)
  • 36. Limitations of lockset analysis: Advantages of lockset analysis: - easy to implement, lightweight, has the potential to scale well (in contrast with happens-before based analyses)
  • 37. Limitations of lockset analysis: - imprecision (a violation of locking discipline is not always a race) Advantages of lockset analysis: - easy to implement, lightweight, has the potential to scale well (in contrast with happens-before based analyses)
  • 38. Limitations of lockset analysis: - imprecision (a violation of locking discipline is not always a race) - code coverage in dynamic tools is limited by execution paths that are explored Advantages of lockset analysis: - easy to implement, lightweight, has the potential to scale well (in contrast with happens-before based analyses)
  • 39. Limitations of lockset analysis: - imprecision (a violation of locking discipline is not always a race) - code coverage in dynamic tools is limited by execution paths that are explored - to counter the latter, we apply lockset analysis in a symbolic context by analysing source code Advantages of lockset analysis: - easy to implement, lightweight, has the potential to scale well (in contrast with happens-before based analyses)
  • 40. We use Read and Write Sets during lockset analysis to keep track of shared memory location accesses — not in previous example for simplicity Some other (driver-specific) optimisations read our paper!
  • 41. Boogie IVL code, instrumented with yields Data Race Reports No Errors (Under Given Bounds) WHOOP Error Traces Z3 Chauffeur SMACK Linux driver source code in C Boogie IVL code llvm-IR Linux Environmental Model Instrumentation Sequentialization Invariant Generation Boogie Verification Engine CORRAL A. Translation Phase B. Symbolic Lockset Analysis Phase C. Bug-Finding Phase Clang / LLVM entry point information Toolchain
  • 42. W Inst Sequ Invari Ve Translation Phase Chauffeur SMACK Linux driver source code in C Boogie IVL code llvm-IR Linux Environmental Model Clang / LLVM entry point information
  • 43. W Inst Sequ Invari Ve Translation Phase Chauffeur SMACK Linux driver source code in C Boogie IVL code llvm-IR Linux Environmental Model Clang / LLVM entry point information
  • 44. W Inst Sequ Invari Ve Translation Phase Chauffeur SMACK Linux driver source code in C Boogie IVL code llvm-IR Linux Environmental Model Clang / LLVM entry point information Debugging information is preserved so that we can map bugs back to C source code
  • 45. Symbolic Lockset Analysis Phase ACK Boogie IVL code entry point information Data Race Reports WHOOP Z3 Instrumentation Sequentialization Invariant Generation Boogie Verification Engine Boogie IVL code, instrumented with yields No Errors (Under Given Bounds) Error Tr CORRAL
  • 46. Symbolic Lockset Analysis Phase ACK Boogie IVL code entry point information Data Race Reports WHOOP Z3 Instrumentation Sequentialization Invariant Generation Boogie Verification Engine Boogie IVL code, instrumented with yields No Errors (Under Given Bounds) Error Tr CORRAL
  • 47. Challenges and Solutions Aliasing is a big challenge — we exploit LLVM alias analyses and SMACK heap modelling Scalability is a big issue — we generate and infer invariants and perform summarisation for modular verification (each procedure verified in isolation) read our paper!
  • 48. - imprecision as it inherits the limitations of lockset analysis Limitations
  • 49. - imprecision as it inherits the limitations of lockset analysis - sound over-approximation of shared state and lock-free data structures can lead to false alarms Limitations
  • 50. - imprecision as it inherits the limitations of lockset analysis - sound over-approximation of shared state and lock-free data structures can lead to false alarms - do not currently handle interrupt handlers in a special way, we just assume they execute concurrently at all times (which however is sound) Limitations
  • 51. To improve Whoop’s precision, we use Corral [5], an industrial strength bug-finder for device drivers from Microsoft Research that is currently used by Microsoft in the backend of the Static Driver Verifier (SDV) Improving precision [5] A. Lal, S. Qadeer, and S. K. Lahiri. A solver for reachability modulo theories. CAV 2012
  • 52. The sequentialised program is bounded by a number of context-switches per thread [6] A. Lal and T. W. Reps. Reducing concurrent analysis under a context bound to sequential analysis. CAV 2008 Corral uses the Lal-Reps sequentialisation [6] to transform a concurrent program into a non-deterministic sequential program Bounded Bug-Finding
  • 53. Bounded Bug-Finding Corral can then explore the sequential program to detect data races, encoded as race-checking assertions If a race is found, a trace (mapped on the original C code) is reported to the user
  • 54. Bug-Finding Phase ie de int ion Data Race Reports WHOOP Z3 Instrumentation Sequentialization Invariant Generation Boogie Verification Engine Boogie IVL code, instrumented with yields No Errors (Under Given Bounds) Error Traces CORRAL
  • 55. State-space explosion Corral inserts a context switch before each shared memory access and at each synchronisation point (e.g. lock/unlock)
  • 56. Problem: this can be too coarse and state- space can explode in large drivers! State-space explosion Corral inserts a context switch before each shared memory access and at each synchronisation point (e.g. lock/unlock)
  • 57. Sound partial-order reduction If our symbolic lockset analysis finds that a given shared memory access is not racy, then we do not instrument a context switch before this memory access
  • 58. This tames the sequentialisation and can greatly speedup Corral as we have found in our experiments Sound partial-order reduction If our symbolic lockset analysis finds that a given shared memory access is not racy, then we do not instrument a context switch before this memory access
  • 59. We applied our technique on 16 drivers from the Linux 4.0 kernel: - block, char, ethernet, nfc, usb and watchdog (250 — 7300 LoC) - exploiting our symbolic lockset analysis we can significantly accelerate Corral by 1.5-20x ! - in 1 driver there was slowdown, because we did not manage to verify race freedom - detected potential races (filled bug report, but have not confirmed yet) Evaluation
  • 60. Whoop Corral Whoop + Corral Benchmarks Time (sec) # Context Switches CSB = 9 Time (sec) # Context Switches CSB = 9 Time (sec) generic_nvram 2.3 92 197.5 29 49.3 pc9736x_gpio 4.1 691 27337.6 167 1358.9 intel_scu_wd 2.4 314 1571.7 196 689.3 fs3270 3.2 321 T.O. (10 hours) 211 8883.0 intel_nfcsim 3.6 732 1539.9 601 278.0 sx8 2.8 227 21.4 217 24.3 Read the paper for more results!
  • 61. Applied our symbolic lockset analysis on >1000 concurrency benchmarks from SVCOMP 2016: - Early results: reducing Corral runtime by ~75% - No bugs missed, gives more confidence in our partial-order reduction! We want to extend our Linux model so that we can apply our technique on more drivers! We want to experiment with applying our technique on other Linux modules (e.g. filesystems) New / Future work