The Verification Grand Challenge

1
The Verification Grand Challenge

• Tony Hoare
• Menlo Park Feb 21, 2005

2
A mature scientific discipline

• Sets its own agenda
• for accumulation of knowledge and skills
• Pursues its own ideals
• of purity, accuracy, generality, certainty
• Poses its own fundamental questions
• to satisfy curiosity, both practical and
  theoretical

3
In Engineering we ask

• What does the product do?
• the specification tells us
• How does it work?
• its internal interface specifications tell us.
• How can we make it better?
• cheaper, more reliable,
• and delivered sooner!

4
In Science we ask more

• Why does the product work?
• The underlying scientific theory explains.
• How does the theory generalise?
• so results apply in different domains.
• How do we know the answers are right?
• by calculation and by convincing experiment,
• reproducible and subject to scrutiny.

5
Verified Programs

• Have precise external specifications
• At appropriate level of soundness, safety,
  security, serviceability, functionality,
• Have complete internal specifications
• of interfaces between components
• With correctness checked by proof
• which should be fully mechanised
• Based on a sound theory of programming
• which should be general and complete

6
A Program Verifier

• was proposed in 1969 as a fully automatic check
  of validity of an explanation why the program
  works.
• It is needed as a basic experimental tool for
  the science of programming.
• Its construction is still a grand challenge
  for research in Computer Science

7
The Human Genome project(1990-2004)

• had a clear set of deliverables,
• a planned route to application,
• in areas of great potential benefit.
• It pursued scientific ideals
• free from commercial pressures.
• Building on the current state of the art
• it looked 15 years ahead,
• and changed the mode of conduct of Science.

8
The Verified Software project

• is modelled on the Human Genome project
• and shares many of its properties
• Does not need glamour or massive funds

9
Clear deliverables

• A comprehensive theory of programming
• concurrency, object orientation, inheritance,
• A coherent toolset based on the theory
• development aids, test case generators,
  harnesses, assertion inference engines, program
  analysers,
• A collection of mechanically verified programs
• safety-critical and embedded codes, open source
  libraries, middleware and desktop applications
• fully verified at high levels of soundness,
  safety, security, serviceability, functional
  correctness.

10
Route to application

• Verified programs will replace existing versions
  in daily use
• subsequent evolution will maintain correctness.
• Verification technology will be integrated into
  commercial toolsets
• for general use by software engineers
• The costs associated with program error will be
  significantly reduced

11

• Based on the software developer and user
  surveys, the national (US) annual costs of an
  inadequate infrastructure for software testing is
  estimated to range from 22.2 to 59.5 billion.
• Over half of these costs are borne by software
  users in the form of error avoidance and
  mitigation activities.
• The remaining costs are borne by software
  developers
• In 2000, total sales of software reached 180
  billion
• The Economic Impacts of Inadequate
  Infrastructure for Software Testing
• (US Dept. Commerce Planning Report 02-03, May
  2002 ).

12
Scientific ideals

• Academic research pursues ideals
• generality of theory,
• of certainty of knowledge
• purity of materials,
• accuracy of measurement,
• and now correctness of programs
• far beyond the current needs of the market place

13
Commercial pressures

• commercial program analysis and development tools
• will follow market demand
• to discover more faults in existing programs
• appealing to current educational level of
  programmers
• preferably with pictorial representations

14
State of the art

• Smart-card applications have been manually proved
  (eg. Logica).
• Safety-critical systems have been developed from
  specification (eg. Praxis).
• Commodity software already includes many
  assertions (eg. Microsoft Office)
• Open Source software is freely available for
  research, as well as for use (eg. Apache).
• Programming theory covers O-O, concurrency (eg.
  Separation Logic, Process algebra ,)

15
Some Available Tools

• Assertion generators
• Program optimisers and analysers
• Type inferencers and checkers
• Abstract Syntax Tree compilers
• Verification Condition Generators
• Program Development Environments
• Code generators

16
Theorem proving

• Proof searchers,
• Constraint solvers,
• Model checkers,
• Decision procedures,
• Algebraic simplifiers

17
Change in conduct of Science

• Commitment to a large and long-term project
• involving collaboration as well as competition
• on an international scale.
• New links between established research schools,
  conference series, journals,
• New criteria for refereeing, research grant
  evaluation, personal promotion,
• Thats why we need a Grand Challenge

18
Determinants of success

• Support of the scientific community
• Skill and enthusiasm of participants
• Strategy for accumulation of results
• by co-operation and competition.
• Standards for inter-operation of tools
• Agreement on challenge codes
• Understanding from funding bodies

19
Public appeal

• Win public confidence and respect.
• Beware of glamour
• manned space flight
• chess playing machine
• the nematode worm

20
First steps

• A verified software repository
• a growing sample of challenge codes, with
• specifications, design paths, assertions,
• test suites, test harnesses, post mortems,
• and an evolving set of analysis tools
• observing standards for inter-operation
• applicable to the challenge codes
• with accumulation of experimental results

21
IFIP Working Conference

• Verified Software
• Theories, Tools and Experiments
• Zurich, October 10-14, 2005
• Chairmen Tony Hoare and Jay Misra
• Organisers Bertrand Meyer, Natarajan Shankar,
  Jim Woodcock
• Participants by invitation

22
A Program Verifier

• One can dream of routinely using a verifying
• compiler as an everyday tool. In the context
• of this idea our work has been extremely
• modest and must be considered as a small
• first step. We only hope that, indeed, this
• has been a first step of a progression which
• will allow this dream to come to fruition.

A Program Verifier Thesis by James C.
King Carnegie Institute of Technology September
1969