Model of C Semantics

1
(No Transcript)
2
http//www.cs.kuleuven.ac.be/conference/EuroSys200
6/papers/p73-ball.pdf
http//www.di.ens.fr/cousot/COUSOTpapers/PLDI03.s
html
3
Rules
Static Driver Verifier
Development
Testing
Source Code
4
SLAM Software Model Checking

• SLAM innovations
• boolean programs a new model for software
• model creation (c2bp)
• model checking (bebop)
• model refinement (newton)
• SLAM toolkit
• built on MSR program analysis infrastructure

5
SLIC

• Finite state language for stating rules
• monitors behavior of C code
• temporal safety properties (security automata)
• familiar C syntax
• Suitable for expressing control-dominated
  properties
• e.g. proper sequence of events
• can encode data values inside state

6
State Machine for Locking
Rel
Acq
Unlocked
Locked
Rel
Acq
Error
7
The SLAM Process
boolean program
c2bp
prog. P
prog. P
slic
bebop
SLIC rule
predicates
path
newton
8
Example
Does this code obey the locking rule?
do KeAcquireSpinLock() nPacketsOld
nPackets if(request) request
request-gtNext KeReleaseSpinLock() nPackets
while (nPackets ! nPacketsOld) KeRelease
SpinLock()
9
Example
Model checking boolean program (bebop)
do KeAcquireSpinLock() if() KeRe
leaseSpinLock() while () KeReleaseSpin
Lock()
U
L
L
L
U
L
U
L
U
U
E
10
Example
Is error path feasible in C program? (newton)
do KeAcquireSpinLock() nPacketsOld
nPackets if(request) request
request-gtNext KeReleaseSpinLock() nPackets
while (nPackets ! nPacketsOld) KeRelease
SpinLock()
U
L
L
L
U
L
U
L
U
U
E
11
Example
Add new predicate to boolean program (c2bp)
b (nPacketsOld nPackets)
do KeAcquireSpinLock() nPacketsOld
nPackets b true if(request) request
request-gtNext KeReleaseSpinLock() nPackets
b b ? false while (nPackets !
nPacketsOld) !b KeReleaseSpinLock()
U
L
L
L
U
L
U
L
U
U
E
12
Example
Model checking refined boolean program (bebop)
b (nPacketsOld nPackets)
do KeAcquireSpinLock() b true
if() KeReleaseSpinLock() b b ?
false while ( !b ) KeReleaseSpinLock
()
U
L
b
L
b
L
b
U
b
!b
L
U
b
L
U
b
U
E
13
Example
Model checking refined boolean program (bebop)
b (nPacketsOld nPackets)
do KeAcquireSpinLock() b true
if() KeReleaseSpinLock() b b ?
false while ( !b ) KeReleaseSpinLock
()
U
L
b
L
b
L
b
U
b
!b
L
U
b
L
b
U
14
Observations about SLAM

• Automatic discovery of invariants
• driven by property and a finite set of (false)
  execution paths
• predicates are not invariants, but observations
• abstraction model checking computes inductive
  invariants (boolean combinations of observations)
• A hybrid dynamic/static analysis
• newton executes path through C code symbolically
• c2bpbebop explore all paths through abstraction
• A new form of program slicing
• program code and data not relevant to property
  are dropped
• non-determinism allows slices to have more
  behaviors

15
Current status of SDV

• Runs on 100s of Windows drivers
• Finds several bugs, proves several properties
• SDV now transferred from MSR to Windows division
• Used to check several DDK and inbox drivers
• Beta Released at WINHEC 2005!

16
Static Driver Verifier
17
Static Driver Verifier

• Driver Parallel port device driver
• Rule Checks that driver dispatch routines do
  not call IoCompleteRequest() twice on the I/O
  request packet passed to it by the OS or another
  driver

18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
Call 1
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
(No Transcript)
33
(No Transcript)
34
Call 2
35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38
Patrick Cousot, Radhia Cousot, Jérôme Feret,
Laurent Mauborgne, Antoine Miné, David Monniaux,
Xavier Rival, Bruno Blanchet
ASTRÉE analyzes structured C programs, without
dynamic memory allocation and recursion.
In Nov. 2003, ASTRÉE automatically proved the
absence of any run-time error in the primary
flight control software of the Airbus A340
fly-by-wire system a program of 132,000 lines of
C analyzed in 1h20 on a 2.8 GHz 32-bit PC using
300 Mb of memory
39
Abstraction RefinementPLDI03 Case Study of
Blanchet et al.

• the initial design phase is an iterative
  manual refinement of the analyzer.
• Each refinement step starts with a static
  analysis of the program, which yields false
  alarms. Then a manual backward inspection of the
  program starting from sample false alarms leads
  to the understanding of the origin of the
  imprecision of the analysis.
• There can be two different reasons for the lack
  of precision
• some local invariants are expressible in the
  current version of the abstract domain but were
  missed
• some local invariants are necessary in the
  correctness proof but are not expressible in the
  current version of the abstract domain.

40

• Q is a safe inductive invariant if
• init ? Q
• Step(Q) ? Q
• Q ? safe

41
(No Transcript)
42
(No Transcript)
43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
(No Transcript)
47
(No Transcript)
48
(No Transcript)
49
(No Transcript)
50
(No Transcript)
51
(No Transcript)
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
http//research.microsoft.com/specsharp/papers/krm
l136.pdf
http//portal.acm.org/citation.cfm?id1134319