The German Verisoft Project
2003 - 2007
W. Paul
Universität Saarbrücken
wiss. Gesamtprojektleiter
bmb+f Projekt Verisoft
Testing System Design
• how do you know that
zero needles are left ?
Measure it !
• how do you know that
zero needles are left ?
• Formal Verification
– correctness proof
– measure number of gaps in
proof by CAV system
– syntax check
Measure it !
• how do you know that
zero needles are left ?
• Formal Verification
– correctness proof
– measure number of gaps in
proof by CAV system
– syntax check
• CAV system = measuring
instrument
– nothing less
– nothing more
In principle we know how to do it...
• Verify software
In principle we know how to do it...
• Verify software
• not just programs
• you cannot possibly be
sure unless you have
done it ???
In principle we know how to do it...
• destroy civilisation
• you cannot possibly be
sure unless you have
done it ???
In principle we know how to do it...
• fly to the moon
• you may be wrong
In principle we know how to do it...
• fly to the moon
• there may be something
missing
In principle we know how to do it...
• fly to the moon
In principle we know how to do it...
• verify software
• was anything (more or
less) serious missing
2003 ?
You don‘t know how to verify software unless you
know how to fully verify
•
•
•
•
•
•
•
drivers
OS kernel written in C
programs making calls to OS
programs using RPC
implementations of crytographic protocols
assembler programs with timer interrupts
......one more !!
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• formal model of
processor + device(s)
• ICCD 05: disk
data paths + control automaton of disk
couple with processor model
•
bufp
w,r
din, adr
dout
eev
stat
cmd
lba
scnt
data
ien
port
RAM
sector
buffer
swap
eifi: transfer sector buffer/swap
done
true eventually
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• formal model of
processor + device(s)
• ICCD 05: disk
• 2006: disk + terminal +
network interface + timer
+ model hierarchy (e.g.
file system)
• a distributed system
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• TPHOLS 05: semantics
of C with in line
assembler code
C0A: C0 with in line assembler code
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• TPHOLS 05: semantics
of C with in line
assembler code
– uses compiler theory
• TPHOLS 05: semantics
of kernel + users
CVM semantics and implementation (1)
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• OS semantics (thesis
Bogarn)
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• RPC semantics: Thesis
Alkassar
• applications : DFKI +
Univ. Koblenz
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• basic math:
– probability
– number theory
• TU Darmstadt + DFKI +
TU Munich + T-Systems
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• Knapp/Paul 2006:
– assembler model does not
see caches
– assembler model inherently
nondeterministic:
– resolve nondeterminism be
worst case execution time
(WCET) analysis (AbsInt)
– on RTL level
Pure WCET above RTL level of processor
• is either by
measurements
– guarantees usually nothing
• or
– like guaranteeing a speed
of at least 4.07 km/h for this
car
• because:
– cache penalties can affect
execution time of an ISA
intruction by factor 100
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• ......one more !!
• Knapp/Paul 2006:
– assembler model does not
see caches
– assembler model inherently
nondeterministic:
– resolve nondeterminism be
worst case execution time
(WCET) analysis (AbsInt)
– on RTL level
– uses theory of procesor
correctness
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• implementation
correctness of e.g. CSP
down to assembler level
• Markt Oberdorf lectures
2006:
• correctness proof for
distributed real time
system
–
–
–
–
FlexRay+OSEKTime (like)
serial interfaces
clock synchronisation
classical theory of program
correctness
– + everything above
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• implementation
correctness of e.g. CSP
down to assembler level
• Markt Oberdorf lectures
2006:
• correctness proof for
distributed real time
system
– serial interfaces
– clock synchronisation
– classical theory of program
correctness
– + everything above
• all in 1 (one) Theory
You don‘t know how to verify software unless you
know how to fully verify
• drivers
• OS kernel written in C
• programs making calls to
OS
• programs using RPC
• implementations of
crytographic protocols
• assembler programs with
timer interrupts
• implementation
correctness of e.g. CSP
down to assembler level
• Markt Oberdorf lectures
2006:
• correctness proof for
distributed real time
system
– serial interfaces
– clock synchronisation
– classical theory of program
correctness
– everything above
• all in 1 (
one
) Theory
Result 1
• One unified mathematical theory of correctness
of computer sysems
– hardware, processors, devices, languages, compilers,
WCET, kernel, OS, RPC
– necessary for pervasive system verification
• Exists on paper
Result 2
• One unified mathematical theory of correctness of
computer sysems
– hardware, processors, devices, languages, compilers, WCET,
kernel, OS, RPC
• System Verification Environment/Repository
–
–
–
–
–
development tools
formal proof tools
equivalence proofs for semantics
formal models
verified components (processor, compiler, kernel, OS,libraries)
• supporting collaborative development of proofs in that
unified theory
Result 2
• One unified mathematical theory of correctness of
computer sysems
– hardware, processors, devices, languages, compilers, WCET,
kernel, OS, RPC
• System Verification Environment/Repository
–
–
–
–
–
development tools
formal proof tools
equivalence proofs for semantics
formal models
verified components (processor, compiler, kernel, OS,libraries)
• supporting collaborative development of proofs in that
unified theory
Result 2.5: productivity
• traditional devlopment of complex software
– 80 % testing
– 50 lines of code (LOC)/person week
• full C program verification
– present state, Hoare logic, VCG
– 10 lines of proof (LOP)/LOC
– up to 30-50 LOC/person week
• productivity comparable now
– with infra structure is in place
Current Activities....
• System Verification Environment/Repository
–
–
–
–
–
development tools
formal proof tools
equivalence proofs for semantics
formal models + proofs
verified components (processor, compiler, kernel, OS,libraries)
• supporting collaborative development of proofs in that
unified theory
• stable portions of repository will successively made
public
– beginning in September 2006
Repository: present and near future
• C-semantics
–
–
–
–
–
–
Hoare Logic
small step; also in line assembler
big step
equivalence big step/Hoare
equivalence big step/small step
Extended state (e.g. C variables + device state)
• Verified Programs and Software
–
–
–
–
–
string library
big number library
compiler; correctness wrt small step; proven in Hoare logic
page fault handler
OS Kernel
Repository: present and near future
• C-semantics
–
–
–
–
–
–
Hoare Logic
small step; also in line assembler
big step
equivalence big step/Hoare
equivalence big step/small step
Extended state (e.g. C variables + device state)
• Verified Programs and Software
–
–
–
–
–
string library
big number library
compiler; correctness wrt small step; proven in Hoare logic
page fault handler (uses everything above)
OS Kernel
Integrated system C0 Verification Environment
• Interactive Provers
– Isabelle/HOL
– VSE
• Integrating Automatic Methods
–
–
–
–
–
–
abstract interpretation
shape analysis
software model checking
counter example guided abstraction refinement
termination analysis
automatic theorem provers
• In Hardware Verification
– degree of automation 97 % (OneSpin solutions)
– cheaper than traditional testing
– more complex than most program correctness proofs
Summary
1. Unified theory of system correctness
•
•
from gates to applications
structure induced by standard systems components
2. Integrated system verification environment
•
•
•
architecture induced by 1
productivity not bad now
Interactive provers + all standard automatic methods
3. If it‘s not verifiable/falsifiable its not science
•
•
checking measurements in CS easier than in
physics
www.verisoft.de